perm filename CLWIND.MSG[COM,LSP]26 blob
sn#855932 filedate 1988-04-14 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂02-Jan-88 1049 CL-Windows-mailer gcontext-function
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Jan 88 10:49:32 PST
Date: 2 Jan 1988 13:46-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: cl-windows@SAIL.STANFORD.EDU
Subject: gcontext-function
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <568147579/rfb@SPICE.CS.CMU.EDU>
In Sun/Lucid Lisp, it appears that all possible values have the same
effect; that of XOR. Could someone send me an example of code that
preforms some graphics operation using a different gcontext-function so
that I can determine whether the brain damage is local?
∂04-Jan-88 0146 CL-Windows-mailer more clx questions
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 01:46:37 PST
Received: from suntoo.sun.com ([192.9.0.45]) by Sun.COM (4.0/SMI-3.2)
id AA25889; Sat, 2 Jan 88 23:45:40 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA05504; Sat, 2 Jan 88 23:46:16 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA03389; Sat, 2 Jan 88 22:53:39 EST
Received: from psilocybin.sun.com by eti.com (3.2/SMI-3.2)
id AA29509; Sat, 2 Jan 88 22:35:34 EST
Received: by psilocybin.sun.com (3.2/SMI-3.2)
id AA00705; Sat, 2 Jan 88 22:35:47 EST
Date: Sat, 2 Jan 88 22:35:47 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8801030335.AA00705@psilocybin.sun.com>
To: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Subject: more clx questions
Why is it that the specification FONT argument for TEXT-WIDTH,
TEXT-EXTENTS, DRAW-GLYPHS, etc. in the keyword arguments comes first
in the distributed implementation when the specification (doc.lisp)
puts it in the keyword arguments. It strikes me that this is an
improvement, but the spec should be updated.
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them? This seems *very*
wrong.
Is there any way to find out how wide a string is without doing any
CONSing?
Why is it that DRAW-GLYPHS accepts a string as the SEQUENCE argument,
but DRAW-GLYPH doesn't accept a character as the ELT argument?
Why is EVENT-LISTEN specified to take a timeout argument? Shouldn't
it return the number of events available ``right now?''
Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂04-Jan-88 1144 CL-Windows-mailer Comments on CLUE
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 11:44:33 PST
Date: 4 Jan 1988 14:44-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: cl-windows@sail.stanford.edu
Subject: Comments on CLUE
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <568323856/rfb@SPICE.CS.CMU.EDU>
Last month, I read through ``Common Lisp User Interface Environment'' and I
have some general comments about the proposal as well as some specific nits
to pick about various things in the document.
First my general comments.
I don't have any immediate plans to use the CLUE software. Instead, I
have modified CLX slightly such that DRAWABLEs, WINDOWs and PIXMAPs are
CLOS classes rather than structures and CREATE-WINDOW accepts a :WINDOW
keyword argument. When the :WINDOW argument is specified,
CREATE-WINDOW destructively modified it rather than consing a new
WINDOW instance. For sub-classes of WINDOW, the instance
initialization process includes calling CREATE-WINDOW on the instance
using itself as the :WINDOW object. The CLX modifications took me less
than an hour to implement and comprise about a page of code.
I've found that this object oriented CLX lets me do the sorts of object
oriented things that I wanted to do without having to adopt all aspects of
CLUE. My opinion is that it would be much better to have a lot of different
people building CLUE-like things using such an interface before making any
serious attempt at standardization, but I wouldn't be terribly shocked to
have others convince me that I'm wrong about this. The X protocol is
relatively stable and I think that CLX is a major win in that it provides a
nice lisp-based interaction paradigm that maps fairly directly onto the
protocol definition. Mostly I think that CLUE is an attempt to standardize
too much too soon.
I also got the impression that a lot of the the (generic) functions proposed
in CLUE are just arbitrary name changes which don't use ``conc-names'' so
that they will have a high probability of causing all sorts of package
conflicts which shouldn't be necessary. PRESENT vs. MAP-WINDOW is one
example of what I'm talking about.
Below are my more specific comments, organized according to the CLUE spec
organization.
Chapter 1
1.3.1 Contacts, Composites and Interactive Streams
Why is it that the default CONTACT class, which has over 70 slots, doesn't
include a slot for children when it is a sub-class of WINDOW which has
children? In specifying my own class hierarchy, I didn't see any need to
make a distinct classes for composite and non-composite objects although I
considered it at first.
Chapter 2
2.1 The Contact Class
Why is the form DEFCONTACT used rather than DEFCLASS? It appears that there
are some typos involving indentation and parenthesization of the massive
DEFCONTACT form.
2.1.1 Contact Creation
In the second paragraph, a reference is made to ``The generic MAKE-INSTANCE
function''. CLOS provides a function named MAKE-INSTANCE, but not a generic
function.
2.2 Defining a Contact Class
DEFCONTACT should not be using ``the property list of the class name symbol
to store information about the resources needed by instances of the class.''
CLOS classes are first-class, specializable objects so there's no need for
such plist hacks.
Chapter 3
In general, I would have guessed that having specializable generic functions
with names like BUTTON-PRESS, etc. and which accepted keyword arguments like
those passed to the CLX event handling function would have been a better
approach than the mechanism proposed in CLUE. To specialize event handling,
one might define a sub-class of WINDOW named BUTTON which specialized
ENTER-WINDOW, BUTTON-PRESS, etc. to invoke other g.f.'s with names like
ACTIVATE-BUTTON, SELECT-BUTTON, FIRE-BUTTON, etc.
3.8.1 Event Specifications
Why is there :UP, but not :DOWN?
3.8.2 Event translation
As I mentioned above, I think that a very different approach is prefereable,
however even if the CLUE approach to event handling is adopted, I don't see
the desireability of specifying an association list. Mostly this is because
of my desire to avoid using lists whenever there's a clean efficient
alternative.
Chapter 6
I think that what this chapter points out the need for the Common Lisp
standard to specify a bit more about what streams are and how one goes about
creating new kinds of streams. Having this all be implementation dependant
is a real pain (especially when using implementations like Lucid which
insist on hiding as much of their internals as possible!)
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂04-Jan-88 1516 CL-Windows-mailer CLX server extension facilities
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 Jan 88 15:16:21 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj01627; 4 Jan 88 17:31 EST
Received: from csc.ti.com by RELAY.CS.NET id az08411; 4 Jan 88 17:15 EST
Received: from SI by tilde id AA01971; Mon, 4 Jan 88 15:51:50 CST
Message-Id: <2777320288-1554914@SI>
Sender: OREN%si.csc.ti.com@RELAY.CS.NET
Date: Mon, 4 Jan 88 15:51:28 CST
From: LaMott Oren <Oren%home.csc.ti.com@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX server extension facilities
One of the things CLX should have had from the beginning is a
mechanism for handling protocol extensions. How does the following
look?
(defmacro define-extension (name &key events errors)
;; Define extension NAME with EVENTS and ERRORS.
;; Note: The case of NAME is important.
;; To define the request, Use:
;; (with-buffer-request (display (extension-opcode ,name)) ,@body)
;; See the REQUESTS file for lots of examples.
;; To define event handlers, use declare-event.
;; To define error handlers, use declare-error and define-condition.
(declare (type stringable name)
(type (list symbol) events errors)))
(defmacro extension-opcode (display name)
;; Returns the major opcode for extension NAME.
;; This is a macro to enable NAME to be interned for fast run-time
;; retrieval.
;; Note: The case of NAME is important.
(declare (type display display)
(type stringable name)
(values card8)))
(defmacro define-error (error-key function)
;; Associate a function with ERROR-KEY which will be called with
;; parameters DISPLAY and REPLY-BUFFER and returns a plist of
;; keyword/value pairs which will be passed on to the error handler.
;; A compiler warning is printed when ERROR-KEY is not defined in a
;; preceding DEFINE-EXTENSION.
;; Note: REPLY-BUFFER may used with the READING-EVENT and READ-type
;; macros for getting error fields. See DECODE-CORE-ERROR for
; an example.
(declare (type symbol error-key)
(type function function)))
;; All core errors use this, so we make it available to extensions.
(defun decode-core-error (display event &optional arg)
;; All core errors have the following keyword/argument pairs:
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; In addition, many have an additional argument that comes from the
;; same place in the event, but is named differently. When the ARG
;; argument is specified, the keyword ARG with card32 value starting
;; at byte 4 of the event is returned with the other keyword/argument
;; pairs.
(declare (type display display)
(type reply-buffer event)
(type (or null keyword) arg)
(values keyword/arg-plist)))
;; This isn't new, just extended.
(defmacro declare-event (event-codes &body declares)
;; Used to indicate the keyword arguments for handler functions in
;; process-event and event-case.
;; Generates functions used in SEND-EVENT.
;; A compiler warning is printed when all of EVENT-CODES are not
;; defined by a preceding DEFINE-EXTENSION.
;; See the INPUT file for lots of examples.
(declare (type (or keyword (list keywords)) event-codes)
(type (alist (field-type symbol) (field-names (list symbol)))
declares)))
(DEFMACRO define-gcontext-accessor (name set-function &optional default-value)
;; This will define a new gcontext accessor called NAME.
;; Defines the gcontext-NAME accessor function and its defsetf.
;; Gcontext's will cache DEFAULT-VALUE and the last value SETF'ed when
;; gcontext-cache-p is true. The NAME keyword will be allowed in
;; CREATE-GCONTEXT, WITH-GCONTEXT, and COPY-GCONTEXT-COMPONENTS.
;; SET-FUNCTION will be called with parameters (GCONTEXT NEW-VALUE)
;; from create-gcontext, force-gcontext-changes, copy-gcontext and
;; copy-gcontext-components.
(DECLARE (type symbol name)
(type function set-function)))
;; To aid extension implementors in attaching additional information to
;; clx data structures, the following accessors (with SETF's) will be
;; defined. GETF can be used on these to extend the structures.
display-plist ;; already exists, but isn't documented
screen-plist
visual-info-plist
gcontext-plist
font-plist
In addition, as an aid for linking CLX windows with toolkit data
structures (without the aid of an additional hash table) I think it
would be good to add drawable-plist.
∂05-Jan-88 1006 CL-Windows-mailer Re: CLX server extension facilities
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Jan 88 10:06:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad12333; 5 Jan 88 12:53 EST
Received: from csc.ti.com by RELAY.CS.NET id aj14314; 5 Jan 88 12:46 EST
Received: from SI by tilde id AA22048; Tue, 5 Jan 88 11:43:31 CST
Message-Id: <2777391745-5850836@SI>
Sender: OREN%si.csc.ti.com@RELAY.CS.NET
Date: Tue, 5 Jan 88 11:42:25 CST
From: LaMott Oren <Oren%home.csc.ti.com@RELAY.CS.NET>
To: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX server extension facilities
In-Reply-To: Msg of Mon, 4 Jan 88 15:51:28 CST from LaMott Oren <Oren@home.csc.ti.com>
I've discovered that define-gcontext-accessor needs a copy-function
parameter. I had previously assumed that the set-function could always
be used for copying. Here's the corrected version:
(DEFMACRO define-gcontext-accessor (name &key default set-function copy-function)
;; This will define a new gcontext accessor called NAME.
;; Defines the gcontext-NAME accessor function and its defsetf.
;; Gcontext's will cache DEFAULT-VALUE and the last value SETF'ed when
;; gcontext-cache-p is true. The NAME keyword will be allowed in
;; CREATE-GCONTEXT, WITH-GCONTEXT, and COPY-GCONTEXT-COMPONENTS.
;; SET-FUNCTION will be called with parameters (GCONTEXT NEW-VALUE)
;; from create-gcontext, and force-gcontext-changes.
;; COPY-FUNCTION will be called with parameters (src-gc dst-gc src-value)
;; from copy-gcontext and copy-gcontext-components.
;; The copy-function defaults to:
;; (lambda (ignore dst-gc value)
;; (if value
;; (,set-function dst-gc value)
;; (error "Can't copy unknown GContext component ~a" ',name)))
(DECLARE (type symbol name)
(type t default)
(type (function (gcontext t) t) set-function) ;; required
(type (or null (function (gcontext gcontext t) t))
copy-function)))
∂05-Jan-88 1551 CL-Windows-mailer more clx questions
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 15:51:40 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 111213; Tue 5-Jan-88 18:51:28 EST
Date: Tue, 5 Jan 88 18:51 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: more clx questions
To: sunpitt!eti!rick@Sun.COM, cl-windows@sail.stanford.edu
In-Reply-To: <8801030335.AA00705@psilocybin.sun.com>
Message-ID: <880105185137.5.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Sat, 2 Jan 88 22:35:47 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Why is it that the specification FONT argument for TEXT-WIDTH,
TEXT-EXTENTS, DRAW-GLYPHS, etc. in the keyword arguments comes first
in the distributed implementation when the specification (doc.lisp)
puts it in the keyword arguments. It strikes me that this is an
improvement, but the spec should be updated.
Changing the documentation seems fine with me.
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them?
They don't.
Is there any way to find out how wide a string is without doing any
CONSing?
Yes, and the current implementation doesn't (at least it didn't when I
tried it on a 36xx).
Why is it that DRAW-GLYPHS accepts a string as the SEQUENCE argument,
but DRAW-GLYPH doesn't accept a character as the ELT argument?
Both accept anything. What I guess you are really asking is why the
existing implementation of TRANSLATE-DEFAULT only does character to
index conversion for strings, as opposed to any sequence containing
characters. One answer is that I don't recall there being any real
resolution of how the default translation should work, or where it
should come from, but perhaps someone can set me straight.
Why is EVENT-LISTEN specified to take a timeout argument? Shouldn't
it return the number of events available ``right now?''
It does if you pass a timeout of zero, which is the default. The
timeout simply provides some additional capability.
Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
Because no one has provided an implementation of BUFFER-READ-DEFAULT
for Lucid that handles timeouts.
∂06-Jan-88 1524 CL-Windows-mailer Re: CLX question
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 15:24:37 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 111615; Wed 6-Jan-88 18:28:34 EST
Date: Wed, 6 Jan 88 18:28 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: CLX question
To: Kimbrough%dsg.csc.ti.com@RELAY.CS.NET
cc: cl-windows@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU
In-Reply-To: <2776980073-2810538@Sierra>
Message-ID: <880106182829.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 31 Dec 87 17:21:13 CST
From: Kerry Kimbrough <Kimbrough%dsg.csc.ti.com@RELAY.CS.NET>
(event-window (GETF event-keys
(CASE event-key
((:configure-request ...) :parent)
((:circulate-notify ...) :event-window)
(otherwise :window)))))
Servicable, but it would be cleaner and more reliable if it was always the same
keyword (say, :event-window). Same goes for event dispatching, too.
(I note that the C Xlib doesn't use uniform names, but uses a
by-position-in-structure kludge when matching windows.)
I would prefer not to make an incompatible change. Better, it seems to
me, is to simply allow use of :event-window on all window-based events,
Thus, for example, :event-window could be used as a synonym for :parent
in :configure-request events.
The only "difficulty" is whether :event-window should be permitted in
queue-event and send-event. It could either be disallowed, or require
that if both synonyms are given they must be equal, or say it "is an
error" if synonyms with differing values are given. Off-hand, I would
lean to "is an error".
∂06-Jan-88 2216 CL-Windows-mailer object oriented CLX patches
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 22:16:36 PST
Received: from suntoo.sun.com (suntoo-bb.sun.com) by Sun.COM (4.0/SMI-3.2)
id AA01768; Wed, 6 Jan 88 22:17:09 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA28089; Wed, 6 Jan 88 22:19:17 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA06461; Wed, 6 Jan 88 23:51:53 EST
Received: by eti.com (3.2/SMI-3.2)
id AA13999; Mon, 4 Jan 88 18:23:49 EST
Date: Mon, 4 Jan 88 18:23:49 EST
From: sunpitt!eti!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8801042323.AA13999@eti.com>
To: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Subject: object oriented CLX patches
Cc: sunpitt!mhb@Sun.COM
Here are the patches that I mentioned in a previous message.
*** original-CLX/clx.lisp Wed Nov 18 06:14:10 1987
--- CLX/clx.lisp Thu Dec 17 23:21:45 1987
***************
*** 69,75 ****
;; Note: all of the following is in the package XLIB.
! (in-package "XLIB" :use '("LISP"))
(defparameter *protocol-major-version* 11.)
(defparameter *protocol-minor-version* 0)
--- 69,75 ----
;; Note: all of the following is in the package XLIB.
! (in-package "XLIB" :use '("LISP" "CLOS"))
(defparameter *protocol-major-version* 11.)
(defparameter *protocol-minor-version* 0)
***************
*** 247,266 ****
(last-width nil :type (or null card29)) ; Accumulated width of last string
(plist) ; hook for extension to hang data
)
;;(deftype drawable () '(or window pixmap))
! (defstruct drawable
! (id 0 :type resource-id)
! (display nil :type (or null display))
! )
! (defstruct (window (:include drawable))
! )
! (defstruct (pixmap (:include drawable))
! )
!
(defstruct colormap
(id 0 :type resource-id)
(display nil :type (or null display))
--- 247,324 ----
(last-width nil :type (or null card29)) ; Accumulated width of last string
(plist) ; hook for extension to hang data
)
+ !
+ ;;; This page has been converted by Rick Busdiecker to make DRAWABLE,
+ ;;; WINDOW and PIXMAP all be Classes rather than Structures.
+ ;;;
;;(deftype drawable () '(or window pixmap))
! ;;; (defstruct drawable
! ;;; (id 0 :type resource-id)
! ;;; (display nil :type (or null display))
! ;;; )
! ;;;
! (defclass drawable ()
! ((id :initform 0)
! (display :initform nil)))
! (defun make-drawable (&rest arguments)
! (apply #'clos:make-instance 'drawable arguments))
! (defun drawable-id (drawable)
! (slot-value drawable 'id))
! (defsetf drawable-id (drawable) (new-drawable-id)
! `(setf (slot-value ,drawable 'id) ,new-drawable-id))
! (defun drawable-display (drawable)
! (slot-value drawable 'display))
! (defsetf drawable-display (drawable) (new-drawable-display)
! `(setf (slot-value ,drawable 'display) ,new-drawable-display))
! (defun drawable-p (object)
! (typep object 'drawable))
! (defun copy-drawable (drawable)
! (make-instance 'drawable
! :id (slot-value drawable 'id)
! :display (slot-value drawable 'display)))
! ;;; (defstruct (window (:include drawable)))
! ;;;
! (defclass window (drawable) ())
! (defun make-window (&rest arguments)
! (apply #'clos:make-instance 'window arguments))
! (defun window-id (window)
! (slot-value window 'id))
! (defsetf window-id (window) (new-window-id)
! `(setf (slot-value ,window 'id) ,new-window-id))
! (defun window-display (window)
! (slot-value window 'display))
! (defsetf window-display (window) (new-window-display)
! `(setf (slot-value ,window 'display) ,new-window-display))
! (defun window-p (object)
! (typep object 'window))
! (defun copy-window (window)
! (make-instance 'window
! :id (slot-value window 'id)
! :display (slot-value window 'display)))
! ;;; (defstruct (pixmap (:include drawable)))
! ;;;
! (defclass pixmap (drawable) ())
! (defun make-pixmap (&rest arguments)
! (apply #'clos:make-instance 'pixmap arguments))
! (defun pixmap-id (pixmap)
! (slot-value pixmap 'id))
! (defsetf pixmap-id (pixmap) (new-pixmap-id)
! `(setf (slot-value ,pixmap 'id) ,new-pixmap-id))
! (defun pixmap-display (pixmap)
! (slot-value pixmap 'display))
! (defsetf pixmap-display (pixmap) (new-pixmap-display)
! `(setf (slot-value ,pixmap 'display) ,new-pixmap-display))
! (defun pixmap-p (object)
! (typep object 'pixmap))
! (defun copy-pixmap (pixmap)
! (make-instance 'pixmap
! :id (slot-value pixmap 'id)
! :display (slot-value pixmap 'display)))
! !
(defstruct colormap
(id 0 :type resource-id)
(display nil :type (or null display))
*** original-CLX/requests.lisp Wed Nov 18 06:14:13 1987
--- CLX/requests.lisp Fri Dec 18 01:24:43 1987
***************
*** 30,36 ****
bit-gravity gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
! colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in
;; the request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
--- 30,45 ----
bit-gravity gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
! colormap cursor
!
! ;;
! ;; This is a hack added by Rick Busdiecker to
! ;; specify the CLOS Class of the object that
! ;; CREATE-WINDOW returns. See more below.
! ;;
! (window nil)
!
! )
;; Display is obtained from parent. Only non-nil attributes are passed on in
;; the request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
***************
*** 53,62 ****
(type (or null (member :none) cursor) cursor))
(declare-values window)
(let* ((display (window-display parent))
! (window (make-window :display display))
! (wid (allocate-resource-id display window 'window))
back-pixmap back-pixel
border-pixmap border-pixel)
(setf (window-id window) wid)
(case background
((nil) nil)
--- 62,92 ----
(type (or null (member :none) cursor) cursor))
(declare-values window)
(let* ((display (window-display parent))
!
! ;;
! ;; This is more of Rick Busdiecker's change. Immediately
! ;; inside this LET* WINDOW is set to the value that it would
! ;; have gotten in the LET* unless CREATE-WINDOW got a non-NIL
! ;; :WINDOW argument.
! ;;
! ;; (window (make-window :display display))
! ;; (wid (allocate-resource-id display window 'window))
! ;;
!
! wid
back-pixmap back-pixel
border-pixmap border-pixel)
+
+ ;;
+ ;; This is the last part of the changes by Rick Busdiecker. It
+ ;; makes WINDOW be an object of class WINDOW unless it is already
+ ;; non-NIL.
+ ;;
+ (if window
+ (setf (window-display window) display)
+ (setf window (make-window :display display)))
+ (setf wid (allocate-resource-id display window 'window))
+
(setf (window-id window) wid)
(case background
((nil) nil)
∂07-Jan-88 1316 CL-Windows-mailer proposed C Xlib changes that CLX should mimic
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 13:16:47 PST
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 7 Jan 88 16:14-EST
Date: Thu, 7 Jan 88 16:18 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: proposed C Xlib changes that CLX should mimic
To: cl-windows@sail.stanford.edu
Message-ID: <880107161840.0.RWS@KILLINGTON.LCS.MIT.EDU>
[I believe :FORCE-OUTPUT-P in XLIB:PROCESS-EVENT and XLIB:EVENT-CASE
should similarly be changed to force output only when blocking to wait
for an event. Note that XLIB:EVENT-LISTEN already does not force
output, which is consistent with the desired new semantics for XPending.
- RWS]
Date: Thu, 7 Jan 88 11:38:17 pst
From: jg@src.dec.com (Jim Gettys)
To: xtensions@ATHENA.MIT.EDU
Subject: Proposed changes to Xlib event routines. IMPORTANT, PLEASE READ!
Recent performance work on the toolkit and server has uncovered an
unfortunate design problem in Xlib. First some history:
The basic internal design of Xlib represents the third attempt, but
for all of that, is 2 1/2 years old. In general, it has served well, but it
predates any serious toolkits, and much understanding of what this would
imply. Joel McCormack and Mike Chow have been working to speed up the
toolkit, and have largely succeeded, with a 2 1/2 time improvement in
creation and startup on some sample programs (one creates 270 widgets!).
One of the problems found and a fix prototyped for is in the
definition of the event handing routines. Currently, they are defined to
ALWAYS flush the output buffer. A concrete example is in order here; let
us use xmh.
1) xmh creates all its windows. In V11, all of this is being
cleverly buffered up in the output buffer (a great improvement
over V10, where no buffering was possible). Xmh maps its top level window
and then goes blocked in XNextEvent, which flushes the buffer.
2) Now the server gets all the window creation requests, and cogitates
for a while. 80 or so subwindows are exposed, and all expose events
are sent to xmh.
3) in xmh, XNextEvent unblocks, and cleverly reads as many events
as it can and enqueues them on the input queue. So far so good.
4) XNextEvent returns the first expose event to the toolkit
5) the toolkit dispatches it, and we find a button has been exposed,
and calls the button widget.
6) The button widget calls a text routine to output 5 or 6
characters of the button label, these are stored in the output buffer,
and it is then finised with its work.
7) the toolkit calls XNextEvent to get the next event.
XNextEvent causes the output buffer to be flushed and a write occurs to
the connection, and we go to step 4. Here is where the problem lies.
So for each of 80 or so exposure events, we end up performing a write call,
rather than having the requests appropriately buffered up and sent in
a single request. At many milliseconds/write, this adds up lots of time,
though before the other performance work was done, it was in the noise,
it is now significant (not to mention the flurry of 80 or so packets
each time xmh was mapped or otherwise exposed). This may account for
of order a second of cpu time in xmh on many workstations, and can
be cut dramatically.
Why does XNextEvent and similar event routines flush at all, you may ask?
It is basically to ensure that programs run correctly without programmers
having to think about the output buffer constantly. If XNextEvent does not
ensure the output buffer is empty before blocking, your program
could easily deadlock; the event you are waiting for may be generated
by a request that was never transmitted if it does not flush the buffer.
Proposed Solution:
------------------
Modify blocking event routines to only flush the output buffer when they
would block, rather than the current semantics of always flushing the
output buffer. Modify non-blocking event (for example XCheckIfEvent)
routines to flush only when they return with no event. For non-blocking
routines, some flush should occur to ensure against deadlock. These
changes are of order a couple lines of code per affected routine. Modify
the Xlib spec to conform. The proposed wording is below. From
experiment, existing programs we have relinked against a modified Xlib
work unchanged with the exception of programs and libraries using
XPending. They may require a flush added before the call to XPending. Old
binaries of course have no risk of problems, as this is strictly a library
change. One should be guaranteed of eventually sending the data if the
routine is called in a loop.
Alternatives:
-------------
1) Doing nothing at all means we live with a very serious performance
bottleneck forever, particularly for toolkits based on Xlib.
2) Provide yet another set of blocking event routines which only flush
when they would block. Retire the old routines, but leave them in the
library.
o advantage: zero risk of breaking code,
o disadvantages: existing code never speeds up, even when
relinked. Two sets of (almost) identical routines exist, causing
confusion.
Opinion:
--------
I believe that it is very unlikely that existing code will break given the
proposed changes to the event routines except for XPending, given our
experience with the code we have in hand. Having two versions of routines
I believe is a very bad idea, even presuming we could figure out other
reasonable names for new versions. Leaving things as they are represents
at least a 25% performance hit for many toolkit applications (at current
performance, more as things get better optimized), not to mention the load
on the network currently being generated.
We desire opinions in particular on whether XPending's definition should
change, as we have had one case in the toolkit where an XFlush had to be
added for it to work with these modifications. Other code tested has not
been affected. XPending is typically only used by quite sophisticated
applications; we believe the impact to be small. If there is sufficient
push back on XPending, there are alternatives such as introducing a new
call, or only flushing when the queue is empty. Our belief at the moment
is that people using XPending should know what they are doing, and it is
not a great idea to have another routine if not really needed, but it is
an alternative if opinion against a change known to cause problems to
existing code is strong.
Proposed changes to the Xlib spec:
----------------------------------
[omitted - RWS]
-----------------
P.S. This problem has been important enough that I have broken my
resolution not to work on X problems for the rest of the time I am a
visitor at SRC (what I do after SRC I have not yet decided). Bob and I
both endorse this change strongly. Your opinions are solicited.
Jim Gettys
Systems Research Center
Digitial Equipment Corporation
∂07-Jan-88 1410 CL-Windows-mailer Re: more clx questions
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 7 Jan 88 14:09:55 PST
Received: from suntoo.sun.com ([192.9.0.45]) by Sun.COM (4.0/SMI-3.2)
id AA12672; Thu, 7 Jan 88 12:44:33 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA05430; Thu, 7 Jan 88 12:45:10 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA08524; Thu, 7 Jan 88 14:28:30 EST
Received: from psilocybin.sun.com by eti.com (3.2/SMI-3.2)
id AA07712; Thu, 7 Jan 88 14:28:31 EST
Received: by psilocybin.sun.com (3.2/SMI-3.2)
id AA03252; Thu, 7 Jan 88 14:29:05 EST
Date: Thu, 7 Jan 88 14:29:05 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8801071929.AA03252@psilocybin.sun.com>
To: sunpitt!sun!ZERMATT.LCS.MIT.EDU!RWS@Sun.COM
Subject: Re: more clx questions
Cc: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Date: Tue, 5 Jan 88 18:51 EST
From: Robert Scheifler <sunpitt!sun!ZERMATT.LCS.MIT.EDU!RWS>
Date: Sat, 2 Jan 88 22:35:47 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them?
They don't.
Yes, they do. Here's an example:
> d
#<DISPLAY psilocybin 0>
> (setf f (open-font d "vtsingle"))
#S(font id-internal 10485767 display #<DISPLAY psilocybin 0> reference-count 1 name "vtsingle" font-info-internal nil char-infos-internal nil local-only-p t)
> (text-extents f "foo")
>>Error: The value #\f, given to REPLACE,
is the wrong type for storing into a (UNSIGNED-BYTE 16) array.
. . .
> (text-width f "foo")
>>Error: The value #\f, given to REPLACE,
is the wrong type for storing into a (UNSIGNED-BYTE 16) array.
Is there any way to find out how wide a string is without doing any
CONSing?
Yes, and the current implementation doesn't (at least it didn't when I
tried it on a 36xx).
Given that TEXT-WIDTH destructively modifies the sequence that it's given, it
seems safer to recons before using it. Instead, I've defined my own function
that iterates over the sequence with CHAR-WIDTH.
Why is it that DRAW-GLYPHS accepts a string as the SEQUENCE argument,
but DRAW-GLYPH doesn't accept a character as the ELT argument?
Both accept anything. What I guess you are really asking is why the
existing implementation of TRANSLATE-DEFAULT only does character to
index conversion for strings, as opposed to any sequence containing
characters. One answer is that I don't recall there being any real
resolution of how the default translation should work, or where it
should come from, but perhaps someone can set me straight.
Actually, I was asking why it appears that DRAW-GLYPH does not accept
characters as the ELT argument. How should I call it so that it does?
Below are example attempts. What issue(s) is/are there about the correct
handling of these attempts?
> root
#<window #524395>
> (setf g (create-gcontext :drawable w :font f :function boole-xor))
#S(gcontext id 10485769 display #<DISPLAY psilocybin 0> drawable #<window #10485768> cache-p t server-state #<Simple-Vector t 27 7FC723> local-state #<Simple-Vector t 27 7FC793>)
> (draw-glyph w g 50 50 65)
t
nil
> (draw-glyph w g 50 50 #\A)
>>Error: #\A should be of type INTEGER
. . .
> (draw-glyph w g 50 50 #\A :translate nil)
>>Error: #\A should be of type INTEGER
Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
Because no one has provided an implementation of BUFFER-READ-DEFAULT
for Lucid that handles timeouts.
One could at least specialize the case where TIMEOUT is 0, which I
would guess to be a somewhat comment case, using the same idea as my
EVENTS-PENDING-P function:
(defun events-pending-p (display)
"Returns T iff there are events pending on display, otherwise NIL."
(and (or (xlib::display-event-queue display)
(progn (display-finish-output display)
(xlib::display-event-queue display)))
t))
Recently, I also asked about using PROCESS-EVENT to get the
functionality of X V10's XUpdateMouse. My understanding of the
responses is that I misunderstood how PROCESS-EVENTS worked. Now I
think that I have a better understanding, but it seems to me that in
implementing this functionality, that is, nuking all pointer-motion
events and returning the coordinates of the last one, I will have to
iterate down the event queue once for each such event. Is there
anyway to search down the queue, leaving most events, but removing
some? Since the function would presumeably be called in an inner loop
of some motion handling facility, efficiency seems fairly important.
It seems to me that to do this efficiently, I have to grab the
event-queue myself, but hopefully I'm just still not understanding
PROCESS-EVENT fully (?) What are the arguments for not making the CLX
interface to the event-queue be the seemingly obvious sequence of
event objects?
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂07-Jan-88 1436 CL-Windows-mailer Re: more clx questions
Received: from ZERMATT.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 14:36:17 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 112127; Thu 7-Jan-88 17:39:28 EST
Date: Thu, 7 Jan 88 17:39 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: Re: more clx questions
To: sunpitt!eti!psilocybin!rick@Sun.COM
cc: cl-windows@sail.stanford.edu
In-Reply-To: <8801071929.AA03252@psilocybin.sun.com>
Message-ID: <880107173925.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Thu, 7 Jan 88 14:29:05 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
Why do TEXT-EXTENTS and TEXT-WIDTH attempt to destructively modify
(via REPLACE) the sequence which is passed to them?
They don't.
Yes, they do. Here's an example:
No, they don't (don't we sound like little kids? :-) First, you seem to
be making a statement about the implementation. The documentation
(admittedly skimpy) makes no mention of destructive modification. It
is useful when you start talking about something to be clear about
how you made your deductions, since the documentation and implementation
are seldom isomorphic. In the case at hand, if you stare at the error
message:
> (text-extents f "foo")
>>Error: The value #\f, given to REPLACE,
is the wrong type for storing into a (UNSIGNED-BYTE 16) array.
you will probably realize that "foo" probably isn't an array of
(UNSIGNED-BYTE 16), so that "foo" isn't being stored into. The problem
here is simply that the V11R1 implementation had an inconsistent
application of the default translation function (i.e. some routines
applied it, some didn't). It so happens that text-extents in V11R1
isn't applying any default translation. This bug has been fixed for
V11R2. In the meantime, if you supply XLIB::TRANSLATE-DEFAULT
explicitly, the code will be happier.
Actually, I was asking why it appears that DRAW-GLYPH does not accept
characters as the ELT argument. How should I call it so that it does?
Well, the V11R1 code as supplied won't let you. This will probably
get fixed for V11R2.
Is there
anyway to search down the queue, leaving most events, but removing
some?
Yes, just have the appropriate cases return nil with :discard-p nil.
The event functions have also been fixed to allow recursive calls,
which also makes things easier.
What are the arguments for not making the CLX
interface to the event-queue be the seemingly obvious sequence of
event objects?
Because then you either have to cons (undesirable) or worry about
alloc/free of resource objects (also undesirable). Also, event-case
allows the possibility of open-coding and extracting only those
components actually required. Also, you have to cons the sequence, or
otherwise contrain the internal event queue allocation mechanism. Also,
parts of the sequence are out on the network, not in memory.
∂12-Jan-88 1023 CL-Windows-mailer Change of address
Received: from emx.utexas.edu ([128.83.1.33]) by SAIL.Stanford.EDU with TCP; 12 Jan 88 10:23:40 PST
Date: Tue, 12 Jan 88 12:23:51 CST
From: ravi@emx.utexas.edu (Ravindra N. Rao)
Posted-Date: Tue, 12 Jan 88 12:23:51 CST
Message-Id: <8801121823.AA09958@emx.utexas.edu>
Received: by emx.utexas.edu (5.54/5.51)
id AA09958; Tue, 12 Jan 88 12:23:51 CST
To: cl-windows@sail.stanford.edu
Subject: Change of address
The host, ngp.utexas.edu on which I used to receive cl-windows mail has
been taken out of service. My new e-mail path is
ravi@emx.utexas.edu
The internet number for this host is 128.83.1.33. This is a new host
and very likely not registerd with sri-nic yet. Thanks.
Ravindra Rao.
∂15-Jan-88 0833 CL-Windows-mailer CLX child coordinate bug
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 08:33:16 PST
Date: 15 Jan 1988 11:01-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: CL-Windows@Sail.Stanford.Edu
Subject: CLX child coordinate bug
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <569260919/rfb@SPICE.CS.CMU.EDU>
I sent this to XPERT, but forgot to put a copy here. I tried making
minor changes to CHANGE-DRAWABLE-GEOMETRY, but wasn't able to get
anything to work. I *really* need to be able to do this and I really
hope that I don't have to wait until XV11R2 or use C call-out if I can
avoid it. If anyone has a solution or even a good educated guess as to
how I can make this work, *please* let me know.
Rick
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Date: Tue, 12 Jan 88 14:52:55 EST
From: sunpitt!eti!psilocybin!rick@Sun.COM (Rick Busdiecker)
To: sunpitt!sun!athena.mit.edu!xpert@Sun.COM
Subject: CLX bug
VERSION:
X11 release 1
SYNOPSIS:
It is not possible to set the position of a window within its parent to
be a negative value using the CLX interface.
DESCRIPTION:
The setf forms for DRAWABLE-X and DRAWABLE-Y expect a value whose type
is CARD32, which is DEFTYPEd to be (UNSIGNED-BYTE 32). Therefore when
a negative integer is used, an error is signaled: ``X-Error: -10 isn't
card32''
REPEAT-BY:
Use CREATE-WINDOW to make a child, CHILD, of a root window.
Evaluate (SETF (DRAWABLE-X CHILD) -10)
FIX:
I would guess that a fix might be to change the CARD32 in the last
form of the CHANGE-DRAWABLE-GEOMETRY definition to be INT16 as is
stated in the January 1987 ``near-release'' of the protocol
specification for the ConfigureWindow request. However, from a quick
look at the code, I would guess that this would allow an application
to set DRAWABLE-WIDTH and DRAWABLE-HEIGHT to negative values as well.
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂18-Jan-88 2101 CL-Windows-mailer help for LISP on SUNs
Received: from space-tech.arpa by SAIL.Stanford.EDU with TCP; 18 Jan 88 21:00:52 PST
Date: 18 Jan 88 22:46:00 CST
From: "Ed Komp" <komp@space-tech.arpa>
Subject: help for LISP on SUNs
To: "cl-windows" <cl-windows@sail.stanford.edu>
Reply-To: "Ed Komp" <komp@space-tech.arpa>
I am not sure that this is the proper place for this request,
but it seems likely that there will be people on this list that
have answers to my questions.
I have a package currently running on DEC VAXstations, and am in the
process of porting it to the SUN.
I am not ready to go for "X" right now because of a very tight deadline.
So, I am interested in contacting individuals with experience
writing applications for SUN workstations in LISP
using the Window Toolkit.
I have questions about tuning the memory management for good performance,
what works well (AND what doesn't), general implementation hints, etc.
thanks very much,
ed komp
------
∂19-Jan-88 1016 CL-Windows-mailer Re: Post conference reflection - object-oriented toolkit
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 10:16:10 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae10635; 19 Jan 88 12:36 EST
Received: from csc.ti.com by RELAY.CS.NET id af15849; 19 Jan 88 12:31 EST
Received: from dsg by tilde id AA19222; Tue, 19 Jan 88 10:49:31 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 19 Jan 88 10:51:43 CST
Message-Id: <2778598189-938917@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Tue, 19 Jan 88 10:49:49 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Len%AIP1%TSD@atc.bendix.com
Cc: <chu%tsd%atc.bendix.com@RELAY.CS.NET>, xpert@ATHENA.MIT.EDU,
cl-windows@SAIL.STANFORD.EDU
Subject: Re: Post conference reflection - object-oriented toolkit
In-Reply-To: Msg of Mon, 18 Jan 88 14:14 EDT from Len%AIP1%TSD@atc.bendix.com
> Regarding the future direction of X, I have but one concern. The
> structure of the Xtk toolkit is clearly evolving toward the
> object-oriented design approach. This, I believe, is a natural and
> very produtive apporach. Yet all widgets are written in vanilla C
> with some conventions adopted. NO object-oriented language support is
> available. I fear that this will cost dearly in the long run.
> ...
> Without an object-oriented language, all manipulation of the objects
> must be done using unenforcable conventions. The syntax is cluttered
> and may become unmaintainable. With an object-oriented language,
> object manipulation become natural and fairly painless. Many possible
> extensions become easier: debugging at object level, storing and
> loading object from databases, garbage collection of unused objects,
> and multiple inheritances.
> ...
> I strongly urge the Xtk toolkit developers to consider this issue.
> The views of others who've done object-oriented programming is also
> very welcome. Speaking personally, this issue is strongly
> discouraging me from using the Xtk toolkit.
> S. Chu <chu%tsd%atc.bendix.com@relay.cs.net>
I heartily concur. I'd like to point out the special implication for CLX users
who program X applications in Common Lisp: callout to a foreign-function Xtk
library is a sandtrap. It may look like a quick way out now, but it won't be
long before you'll wish you were using the standard CLOS OOPS like everybody
else. Then, you'll find that the half of the Xtk machinery which is devoted to
simulating an OOPS will be unnecessary.
∂19-Jan-88 1125 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 11:25:31 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab12006; 19 Jan 88 14:07 EST
Received: from csc.ti.com by RELAY.CS.NET id ac16367; 19 Jan 88 14:01 EST
Received: from SI by tilde id AA20764; Tue, 19 Jan 88 11:57:58 CST
Message-Id: <2778602234-797592@SI>
Sender: OREN@si.csc.ti.com
Date: Tue, 19 Jan 88 11:57:14 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX and Lowercase Alphabetic Keysyms
I've been implementing the keycode->character function for the
clx-extensions and ran into a problem:
Background:
Keycodes (from an event) are translated to keysyms (from the
keyboard-mapping supplied by the server) in the keycode->keysym
function. One of the parameters to keycode->keysym is the
keysym-index, which is essentially the shift-state, and is computed by
the keysym-index function based on the modifier-state and an
indication of whether or not the keysym is both-case alphabetic.
(The caps-lock key only shifts both-case alphabetic keys.)
The define-keysym function provides a mapping from keysyms to
arbitrary lisp objects and keysym-translate functions. Once a keycode
is translated to a keysym, the keysym is translated to an object by
looking up the object associated with the keysym and calling the
associated keysym-translate function with the display, object and
modifier state. The keysym-translate function merges the modifier
state with the object. The result is returned by keycode->character.
The keyboard-mapping returned by the X server doesn't contain the
keysyms for lower-case alphabetic keys (see chapter 6 of the X Window
System Protocol document).
Problems:
1. Because the keyboard-mapping doesn't include lowercase keysyms,
keycode->keysym returns uppercase keysyms for lowercase keys.
There is no keysym-downcase function.
2. In order to interpret the caps-lock modifier, its necessary to have
a keysym-both-case-p predicate, which doesn't exist.
3. Character case isn't passed in to the keysym-translate function,
so it must be re-computed, which is both inefficient and possibly
inconsistent with the computation in keysym-index. Also, in order
for an application to change the details of how the lock modifier
affects control keys and such, all the character translations must
change.
4. Define-keysym maps keysyms to arbitrary lisp objects. It's not
possible to downcase arbitrary objects, or apply control/meta
modifiers so specialized keysym-translate functions are required.
5. A define-keysym with a lowercase keysym will never be used, because
the server keyboard-mapping may not contain them.
To fix:
Either:
Define a new bit in the modifier state ":caps" for use in the
modifier-state passed into the keysym-translate function. This
would be set when (ODDP keysym-index) [The keysym-index convention
is that 0 is for unshifted and 1 is shifted. It may be 2 or 3 if
the keyboard-mapping contains more than one character set].
This localizes shift-lock computations to the keysym-index
function. The meaning of the :caps bit is "this keysym is shifted"
by some combination of the other modifiers. The make-state-mask
and make-state-keys functions would be modified to know about the
:caps bit.
OR:
Define a keysym-downcase function and modify keycode->keysym to
convert uppercase keysyms. This allows the character case to be
communicated to the keysym translate function via the keysym,
instead of with a :caps modifier-state bit.
[This is the solution I prefer. Does anyone know WHY X doesn't put
lowercase keysyms in the keyboard-mapping? If this is actually
useful, then perhaps hiding the convention isn't a good idea and
the :caps bit proposal would be better.]
IN ADDITION, define a keysym-both-case-p predicate and modify
define-keysym as follows:
(defun define-keysym (object keysym &key modifiers mask display
lowercase
(translate #'default-keysym-translate))
;; Define the translation from keysym/modifiers to a (usually
;; character) object.
;;
;; MODIFIERS is either a modifier-mask or list containing intermixed
;; keysyms and state-mask-keys specifying when to use this
;; keysym-translation.
;;
;; MASK is either a modifier-mask or list containing intermixed
;; keysyms and state-mask-keys specifying which modifiers to look at
;; (i.e. modifiers not specified are don't-cares)
;;
;; If DISPLAY is specified, the translation will be local to DISPLAY,
;; otherwise it will be the default translation for all displays.
;;
;; LOWERCASE is used for uppercase alphabetic keysyms. The value
;; is the associated lowercase keysym. This information is used
;; by the keysym-both-case-p predicate (for caps-lock computations)
;; and by the keysym-downcase function.
;;
;; TRANSLATE will be called with parameters (display state OBJECT)
;; when translating KEYSYM and modifiers and mask are satisfied.
;; [e.g (zerop (logxor (logand state (or mask -1)) (or modifiers 0)))
;; when mask and modifiers aren't lists of keysyms]
;;
(declare (type (or string-char t) object)
(type keysym keysym)
(type (or null state-mask (list (or keysym state-mask-key)))
modifiers mask)
(type (or null display) display)
(type (or null keysym) lowercase)
(type (function (display card16 t) t) translate)))
Comments? Does anyone have another proposal? Please respond in time for
me to complete the implementation before the Feb 1 release 2 cutoff.
-LaMott
P.S. Isn't it amazing how complicated character translation can get?
∂19-Jan-88 1217 CL-Windows-mailer help for LISP on SUNs
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 12:16:54 PST
Received: by labrea.Stanford.EDU; Tue, 19 Jan 88 12:17:00 PST
Received: from rainbow-warrior.lucid.com by edsel id AA11180g; Tue, 19 Jan 88 12:08:42 PST
Received: by rainbow-warrior id AA09113g; Tue, 19 Jan 88 12:11:21 PST
Date: Tue, 19 Jan 88 12:11:21 PST
From: Zachary Smith <edsel!zach@labrea.Stanford.EDU>
Message-Id: <8801192011.AA09113@rainbow-warrior.lucid.com>
To: labrea!komp@SPACE-TECH.ARPA
Cc: cl-windows@sail.stanford.edu
In-Reply-To: "Ed Komp"'s message of 18 Jan 88 22:46:00 CST <8801190732.AA08517@edsel.lucid.com>
Subject: help for LISP on SUNs
I probably know as much as anyone else about what is possible and what isn't
on the Sun with the Window Toolkit. If you have window-specific questions you
are welcome to send them to me. I would be happy to help you out if I can.
z
∂19-Jan-88 2115 CL-Windows-mailer CLX :force-output-p and event-listen
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jan 88 21:15:44 PST
Received: from relay2.cs.net by RELAY.CS.NET id bm18988; 19 Jan 88 23:46 EST
Received: from csc.ti.com by RELAY.CS.NET id ad00302; 19 Jan 88 22:04 EST
Received: from home by tilde id AA00408; Tue, 19 Jan 88 19:36:09 CST
Received: from SI by home id AA25385; Tue, 19 Jan 88 17:06:03 CST
Message-Id: <2778620689-1906519@SI>
Sender: OREN@si.csc.ti.com
Date: Tue, 19 Jan 88 17:04:49 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX :force-output-p and event-listen
In-Reply-To: Msg of Tue, 12 Jan 88 07:34 EST from Robert Scheifler <RWS@zermatt.lcs.mit.edu>
> [I believe :FORCE-OUTPUT-P in XLIB:PROCESS-EVENT and XLIB:EVENT-CASE
> should similarly be changed to force output only when blocking to wait
> for an event. Note that XLIB:EVENT-LISTEN already does not force
> output, which is consistent with the desired new semantics for
> XPending. - RWS]
It seems to me that with this change, :force-output-p should default to T
in both process-event and event-case. What do you think?
Also, the current implementation of event-listen doesn't go and read new
events when there are events queued, making counts above zero
meaningless. It seems to me that event-listen should either return a
boolean, or always listen-for and queue new events (making it more
expensive). Returning a boolean would be more consistent with the
common-lisp listen function, while returning a number gives more
information. Is it ever necessary to know how much greater than one the
event list is? Which would you do?
When event-case and process-event are called recursively, they don't
look at events that have been previously processed, but not
deleted. It seems to me that event-listen should do the same.
I'll make this change, unless someone objects.
∂20-Jan-88 0805 CL-Windows-mailer CLX questions
Received: from aai1 ([128.18.4.91]) by SAIL.Stanford.EDU with TCP; 20 Jan 88 08:05:07 PST
Received: from localhost by aai1 (3.2/5.00)
id AA03910 for cl-windows@sail.stanford.edu; Wed, 20 Jan 88 08:03:35 PST
Message-Id: <8801201603.AA03910@aai1>
To: cl-windows@sail.stanford.edu
Organization: SRI International, Menlo Park, CA
Phone: Office--415/859-3759 Home--415/364-2221
Subject: CLX questions
Date: Wed, 20 Jan 88 08:03:22 PST
From: Marie Bienkowski <bienk@spam.istc.sri.com>
I have a couple of questions:
1. Can anyone tell me the status of the standardization comittee's
work on defining a common lisp window standard?
2. Given that CLX is one day going to be replaced by a lisp window toolkit
(e.g., CLUE), is there any benefit to be obtained from using CLX today?
The two reasons I can think of are increased edification (intellectual,
not moral, although using it probably builds character!) and having
something that works with X *today*.
3. How close is clx to being finalized? How successful have people been
in using it? (I know there are some people on the xpert mailing list
discussing it.) What sort of things are possible with it, with minimum
difficulty, e.g., menus, buttons, all the standard sort of stuff?
Any feedback will be appreciated.
Marie Bienkowski
bienk@istc.sri.com
∂21-Jan-88 1851 CL-Windows-mailer Re: CLX :force-output-p and event-listen
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 88 18:51:13 PST
Date: 21 Jan 1988 21:17-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: CL-Windows@Sail.Stanford.Edu
Subject: Re: CLX :force-output-p and event-listen
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <569816261/rfb@SPICE.CS.CMU.EDU>
Date: Tue, 19 Jan 88 17:04:49 CST
From: LaMott Oren <Oren@home.csc.ti.com>
It seems to me that with this change, :force-output-p should default to T
in both process-event and event-case. What do you think?
Sounds right to me.
Also, the current implementation of event-listen doesn't go and read new
events when there are events queued, making counts above zero
meaningless.
I agree, the ``extra information'' isn't accurate and therefore
potentially misleading. I vote for making EVENT-LISTEN a simple
predicate by default and possibly accepting some keyword argument(s)
which make it do otherwise.
BTW Why are the values for :OVERRIDE-REDIRECT :ON and :OFF instead of T
and NIL?
Rick Busdiecker
Expert Technologies, Inc.
sunpitt!eti!rick@eti.com
or
rfb@cs.cmu.edu
∂22-Jan-88 1644 CL-Windows-mailer Re: CLX :force-output-p and event-listen
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Jan 88 16:43:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id af04412; 22 Jan 88 17:22 EST
Received: from csc.ti.com by RELAY.CS.NET id ab18438; 22 Jan 88 17:11 EST
Received: from SI by tilde id AA18090; Fri, 22 Jan 88 12:42:48 CST
Message-Id: <2778864099-4249948@SI>
Sender: OREN@si.csc.ti.com
Date: Fri, 22 Jan 88 12:41:39 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: Rick.Busdiecker@CS.CMU.EDU
Cc: CL-Windows@SAIL.STANFORD.EDU
Subject: Re: CLX :force-output-p and event-listen
In-Reply-To: Msg of 21 Jan 1988 21:17-EST from Rick.Busdiecker@SPICE.CS.CMU.EDU
BTW Why are the values for :OVERRIDE-REDIRECT :ON and :OFF instead of T
and NIL?
This was discussed during the CLX design. Here's part of the discussion:
------- Forwarded Message
Date: Sat, 2 May 87 11:10 EDT
From: Robert Scheifler <RWS@zermatt.lcs.mit.edu>
Subject: NIL in CLX
To: cl-windows@sail.stanford.edu
A few people have said they would prefer the gcontext accessors to
signal an error rather than return the "wrong" value. After I thought
about this, I finally realized what was meant. The original plan I had
for gcontext components was that NIL was never a legal value. This is
true of everything but (I see now) the clip-mask, for which an empty
sequence is legal (if unusual, since it effectively disables all
graphics output, which is different from :none, which is a full-drawable
clip). [An empty dashes sequence is not legal.] My intent was that
accessors would return NIL to indicate "unknown", rather than
signalling, because checking for NIL seems more convenient than handling
signals.
Note that even if a gcontext has caching enabled, it won't always be
possible for the accessors to return a correct value. This is true of
the default tile, stipple, and font values (I suppose :default could be
returned, but I don't really think setf should accept :default), but
also any copying from an uncached to a cached gc will "infect"
components of the cached gc with unknown values.
Related to this is the fact that I have defined create-window,
create-gc, and with-gc (and others) so that passing a keyword argument
as NIL is the same as not passing it. That is, NIL means "ignore me".
I thought this was important for create-window and create-gc, because I
have been burned by wanting to provide a function at a higher level that
accepts some or all of the same keyword arguments, and then pass them
down; either you have to propagate knowledge of default values, or you
have to use a rest argument or some other hackery. Making a few values
:on, :off, and :none seemed worth it to preserve NIL as an ignore value.
I would like to hear comments on all of this. Is it useful to retain
NIL as "ignore" and "unknown"? The void clip-mask is the only conflict
that I can see. If these uses of NIL are removed, then all instances of
:none could be changed to NIL except in clip-mask, and all instances of
(member :on :off) could be changed to boolean, and presumably gcontext
accessors would be defined to signal for unknown components.
------- End of Forwarded Message
∂23-Jan-88 0806 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:06:13 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116177; Sat 23-Jan-88 11:10:09 EST
Date: Sat, 23 Jan 88 11:06 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX and Lowercase Alphabetic Keysyms
To: Oren@home.csc.ti.com, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2778602234-797592@SI>
Message-ID: <880123110611.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 19 Jan 88 12:57 EST
From: LaMott Oren <Oren@home.csc.ti.com>
Define a keysym-downcase function and modify keycode->keysym to
convert uppercase keysyms. This allows the character case to be
communicated to the keysym translate function via the keysym,
instead of with a :caps modifier-state bit.
Sounds fine with me.
Does anyone know WHY X doesn't put lowercase keysyms in the
keyboard-mapping?
It doesn't *require* the lowercase keysyms, which isn't the same as
outlawing them. Not requiring them allows the server to provide an
"exact" representation of the physical engravings on the key. Some
people viewed that as desirable, and the belief is that if clients have
sufficient knowledge to "understand" the keysym, then they will have
enough to understand case transformation.
∂23-Jan-88 0806 CL-Windows-mailer CLX and Lowercase Alphabetic Keysyms
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:06:40 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116178; Sat 23-Jan-88 11:10:27 EST
Date: Sat, 23 Jan 88 11:06 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX and Lowercase Alphabetic Keysyms
To: Oren%home.csc.ti.com@relay.cs.net, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2778602234-797592@SI>
Message-ID: <880123110638.8.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 19 Jan 88 12:57 EST
From: LaMott Oren <Oren@home.csc.ti.com>
Define a keysym-downcase function and modify keycode->keysym to
convert uppercase keysyms. This allows the character case to be
communicated to the keysym translate function via the keysym,
instead of with a :caps modifier-state bit.
Sounds fine with me.
Does anyone know WHY X doesn't put lowercase keysyms in the
keyboard-mapping?
It doesn't *require* the lowercase keysyms, which isn't the same as
outlawing them. Not requiring them allows the server to provide an
"exact" representation of the physical engravings on the key. Some
people viewed that as desirable, and the belief is that if clients have
sufficient knowledge to "understand" the keysym, then they will have
enough to understand case transformation.
∂23-Jan-88 0828 CL-Windows-mailer CLX :force-output-p and event-listen
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 08:28:06 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116185; Sat 23-Jan-88 11:32:03 EST
Date: Sat, 23 Jan 88 11:27 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX :force-output-p and event-listen
To: Oren%home.csc.ti.com@relay.cs.net, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2778620689-1906519@SI>
Message-ID: <880123112752.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Tue, 19 Jan 88 17:04:49 CST
From: LaMott Oren <Oren@home.csc.ti.com>
> [I believe :FORCE-OUTPUT-P in XLIB:PROCESS-EVENT and XLIB:EVENT-CASE
> should similarly be changed to force output only when blocking to wait
> for an event.
It seems to me that with this change, :force-output-p should default to T
in both process-event and event-case. What do you think?
I suppose it might depend on whether you think the normal case is for a
single process to mix input and output, or whether you will have a
separate process reading the events. Also, the non-forcing case can be
viewed as a convenient way to not have to do an event-listen first. I
don't have a very strong opinion either way, which leans to leaving it
as is.
Also, the current implementation of event-listen doesn't go and read new
events when there are events queued, making counts above zero
meaningless.
This just seems like an implementation detail/defect.
It seems to me that event-listen should either return a
boolean, or always listen-for and queue new events (making it more
expensive).
I would say it is acceptable for event-listen to work as follows: if
there are already locally queued events, return that number, else wait
within the timeout for an event, but read as many as possible at that
time. This makes a count meaningful without making it always expensive.
When event-case and process-event are called recursively, they don't
look at events that have been previously processed, but not
deleted. It seems to me that event-listen should do the same.
Yes.
∂23-Jan-88 0931 CL-Windows-mailer CLX questions
Received: from ZERMATT.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 09:31:09 PST
Received: from KILLINGTON.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 116193; Sat 23-Jan-88 12:35:08 EST
Date: Sat, 23 Jan 88 12:31 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX questions
To: bienk@spam.istc.sri.com, cl-windows@sail.stanford.edu
In-Reply-To: <8801201603.AA03910@aai1>
Message-ID: <880123123120.2.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Wed, 20 Jan 88 08:03:22 PST
From: Marie Bienkowski <bienk@spam.istc.sri.com>
2. Given that CLX is one day going to be replaced by a lisp window toolkit
(e.g., CLUE), is there any benefit to be obtained from using CLX today?
Whether something "replaces" CLX depends on how encompassing you thing a
"toolkit" is. As an example, the C Xtk toolkit does not attempt to
provide a graphics interface (although it does provide for some graphics
context management), it leaves the widget writer to use the standard C
Xlib graphics calls. The Andrew toolkit, on the other hand, provides
(mandates) its own graphics interface; this approach can be troublesome
if the interface does not provide the full functionality of the
underlying system.
3. How close is clx to being finalized?
What is there in release 1 is reasonably solid. There is more coming,
that has been discussed on this list. I believe what will pull together
for release 2 will still need a few months review.
How successful have people been
in using it?
I use it all the time (almost exclusively) for debugging servers.
What sort of things are possible with it, with minimum
difficulty, e.g., menus, buttons, all the standard sort of stuff?
All that "stuff" sounds like toolkit stuff, and you won't find it in CLX.
∂23-Jan-88 1329 CL-Windows-mailer CLX questions
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jan 88 13:29:04 PST
Received: from OWL.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 327066; Sat 23-Jan-88 16:28:25 EST
Date: Sat, 23 Jan 88 16:28 EST
From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
Subject: CLX questions
To: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>, bienk@spam.istc.sri.com
cc: cl-windows@sail.stanford.edu
In-Reply-To: <880123123120.2.RWS@KILLINGTON.LCS.MIT.EDU>
Message-ID: <19880123212813.3.MMCM@OWL.SCRC.Symbolics.COM>
Date: Sat, 23 Jan 88 12:31 EST
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Date: Wed, 20 Jan 88 08:03:22 PST
From: Marie Bienkowski <bienk@spam.istc.sri.com>
2. Given that CLX is one day going to be replaced by a lisp window toolkit
(e.g., CLUE), is there any benefit to be obtained from using CLX today?
Whether something "replaces" CLX depends on how encompassing you thing a
"toolkit" is.
CLUE should be implemented using CLX. Therefore, even if no one other
than the CLUE implementers ever programs in CLX, its benefit remains.
Furthermore, it allows a multitude of other toolkits to be investigated.
∂24-Jan-88 1337 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
Received: from ATHENA (ATHENA.MIT.EDU) by SAIL.Stanford.EDU with TCP; 24 Jan 88 13:36:44 PST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA27719; Sun, 24 Jan 88 16:36:21 EST
Received: by JASON.MIT.EDU (5.45/4.7) id AA10317; Sun, 24 Jan 88 15:23:30 EST
Message-Id: <8801242023.AA10317@JASON.MIT.EDU>
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and Lowercase Alphabetic Keysyms
In-Reply-To: Your message of Tue, 19 Jan 88 11:57:14 -0600.
<2778602234-797592@SI>
Date: Sun, 24 Jan 88 15:23:27 EST
From: Roman J. Budzianowski <roman@ATHENA.MIT.EDU>
This problem is handled by C XLIB in a reasonable and efficient way.
The first time the keyboard-mapping is needed, it is requested from
the server and then it is modified to replace entries like (90 0)
by (122 90). Why not use this approach ?
Roman.
∂24-Jan-88 1545 CL-Windows-mailer Ignored values
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 15:45:29 PST
Date: 24 Jan 1988 18:43-EST
From: Steve.Handerson@SPICE.CS.CMU.EDU
To: cl-windows@sail.stanford.edu
Subject: Ignored values
Message-Id: <570066203/skh@SPICE.CS.CMU.EDU>
How about making NIL be false and having the parameter's
default be :undefined?
Similarly, why not put :ignore in slots of things you
don't want inherited?
Yes, it's unfortunate that NIL means so many things.
It tends to be confusing.
-- Steve
∂24-Jan-88 1615 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 16:15:31 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA27212; Sun, 24 Jan 88 16:16:13 PST
Received: from frozen by franz (5.5/3.14)
id AA05735; Sun, 24 Jan 88 15:49:09 PST
Received: by frozen (3.2/3.14)
id AA02798; Sun, 24 Jan 88 15:42:39 PST
Return-Path: <frozen!jdi>
Message-Id: <8801242342.AA02798@frozen>
To: Roman J. Budzianowski <ATHENA.MIT.EDU!roman@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX and Lowercase Alphabetic Keysyms
In-Reply-To: Your message of Sun, 24 Jan 88 15:23:27 EST.
<8801242023.AA10317@JASON.MIT.EDU>
Date: Sun, 24 Jan 88 15:42:38 PST
From: John Irwin <franz!frozen!jdi@ucbarpa.Berkeley.EDU>
Right after you open the display, do:
(setq *X-keysyms* (xlib:keyboard-mapping x-display))
(do* ((i (xlib:display-min-keycode x-display) (1+ i))
(max (xlib:display-max-keycode x-display))
(one (aref *X-keysyms* i 0) (if (<= i max) (aref *X-keysyms* i 0)))
(two (aref *X-keysyms* i 1) (if (<= i max) (aref *X-keysyms* i 1))))
((> i max))
(cond ((and (<= one #x5a) (>= one #x41) (zerop two))
(setf (aref *X-keysyms* i 1) one)
(setf (aref *X-keysyms* i 0) (+ one 32)))
((and (plusp (logand one #xff00)) (zerop two))
(setf (aref *X-keysyms* i 1) one))))
Note that the second part of the cond isn't neccessary to map lower case
correctly, it just handles special keys.
-- John (jdi%franz.UUCP@ucbarpa.Berkeley.EDU)
--------
Your message:
This problem is handled by C XLIB in a reasonable and efficient way.
The first time the keyboard-mapping is needed, it is requested from
the server and then it is modified to replace entries like (90 0)
by (122 90). Why not use this approach ?
Roman.
--------
∂25-Jan-88 1250 CL-Windows-mailer Re: CLX and Lowercase Alphabetic Keysyms
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 12:47:30 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab16033; 25 Jan 88 14:28 EST
Received: from csc.ti.com by RELAY.CS.NET id aj07230; 25 Jan 88 14:14 EST
Received: from SI by tilde id AA24464; Mon, 25 Jan 88 12:48:31 CST
Message-Id: <2779123632-3327935@SI>
Sender: OREN@si.csc.ti.com
Date: Mon, 25 Jan 88 12:47:12 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: John Irwin <franz!frozen!jdi@UCBARPA.BERKELEY.EDU>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX and Lowercase Alphabetic Keysyms
In-Reply-To: Msg of Sun, 24 Jan 88 15:42:38 PST from John Irwin <franz!frozen!jdi@ucbarpa.berkeley.edu>
Right after you open the display, do:
...
(setf (aref *X-keysyms* i 0) (+ one 32)))
...
This isn't general enough to handle arbitrary keymaps (for an example,
see the Cryllic keysyms). That's why I proposed having a :lowercase
parameter on the define-keysym function. However, it may be a good
idea to fix-up the keyboard mapping once, instead of dealing with it on
every keystroke.
Thanks for the response.
LaMott
∂25-Jan-88 1649 CL-Windows-mailer Re: CLX :force-output-p and event-listen
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 16:48:53 PST
Received: from relay2.cs.net by RELAY.CS.NET id ag18896; 25 Jan 88 17:34 EST
Received: from csc.ti.com by RELAY.CS.NET id aj07944; 25 Jan 88 17:11 EST
Received: from dsg by tilde id AA28690; Mon, 25 Jan 88 15:58:01 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 25 Jan 88 11:19:15 CST
Message-Id: <2779118322-14245288@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Mon, 25 Jan 88 11:18:42 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX :force-output-p and event-listen
In-Reply-To: Msg of Tue, 19 Jan 88 17:04:49 CST from LaMott Oren <Oren@home.csc.ti.com>
> It seems to me that with this change, :force-output-p should default
> to T in both process-event and event-case. What do you think?
Agreed.
> Also, the current implementation of event-listen doesn't go and read
> new events when there are events queued, making counts above zero
> meaningless. It seems to me that event-listen should either return a
> boolean, or always listen-for and queue new events (making it more
> expensive). Returning a boolean would be more consistent with the
> common-lisp listen function, while returning a number gives more
> information. Is it ever necessary to know how much greater than one
> the event list is? Which would you do?
I'd prefer to make event-listen an inexpensive boolean.
> When event-case and process-event are called recursively, they don't
> look at events that have been previously processed, but not deleted.
> It seems to me that event-listen should do the same. I'll make this
> change, unless someone objects.
No objection here.
∂25-Jan-88 1650 CL-Windows-mailer Re: Comments on CLUE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Jan 88 16:50:21 PST
Received: from relay2.cs.net by RELAY.CS.NET id aq18896; 25 Jan 88 17:35 EST
Received: from csc.ti.com by RELAY.CS.NET id an07944; 25 Jan 88 17:12 EST
Received: from dsg by tilde id AA28856; Mon, 25 Jan 88 16:02:14 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 25 Jan 88 14:30:08 CST
Message-Id: <2779129778-14933568@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Mon, 25 Jan 88 14:29:38 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Rick.Busdiecker@CS.CMU.EDU
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: Comments on CLUE
In-Reply-To: Msg of 4 Jan 1988 14:44-EST from Rick.Busdiecker@spice.cs.cmu.edu
Thanks for your review. Sorry that it's taken so long to reply, but things have
been busy here in CLUEland, as we prepare to make prototype code publicly
available. Was it Colonel Mustard in the cloak room with the drill press? Stay
tuned.
> Mostly I think that CLUE is an attempt to standardize too much too
> soon.
I share your misgivings about premature standardization of UI sw; CLUE, too,
salutes the "policy-free" approach. And CLUE is just one proposed mechanism. I
agree that standardization will not really take place until some proposal has
acquired enough experience and review to motivate lots of people to adopt it.
That's why we're very interested in learning specifically where you think CLUE
is "too much" or is lacking.
> Why is it that the default CONTACT class, which has over 70 slots,...
This is a common misconception, which the next document ought to work harder to
prevent. Most of the stuff in the defcontact form are resource declarations. In
fact, the contact class has 2 class slots and 14 instance variables (of which 8
are "shadow" copies of X window attributes).
> In specifying my own class hierarchy, I didn't see any need to make a
> distinct classes for composite and non-composite objects although I
> considered it at first.
We, too, considered both alternatives. The chief argument in favor of a distinct
composite class is that, at the contact level, parenthood implies a geometry
mgmt responsibility. Indeed, it was argued that geometry mgmt could reside
nowhere but in the parent contact. But geometry mgmt is too heavy a burden for
all contacts to carry; hence, the composite class.
> Why is the form DEFCONTACT used rather than DEFCLASS?
DEFCONTACT wraps extra processing related to resources around DEFCLASS.
> DEFCONTACT should not be using ``the property list of the class name
> symbol to store information about the resources needed by instances of
> the class.'' CLOS classes are first-class, specializable objects so
> there's no need for such plist hacks.
Good point. This is really an implementation-specific detail. The document will
be changed to allow other non-plist implementations.
> In general, I would have guessed that having specializable generic
> functions with names like BUTTON-PRESS, etc. and which accepted
> keyword arguments like those passed to the CLX event handling function
> would have been a better approach than the mechanism proposed in CLUE.
> To specialize event handling, one might define a sub-class of WINDOW
> named BUTTON which specialized ENTER-WINDOW, BUTTON-PRESS, etc. to
> invoke other g.f.'s with names like ACTIVATE-BUTTON, SELECT-BUTTON,
> FIRE-BUTTON, etc.
There are three advantages to the CLUE approach. First, better consolidation of
event dispatching. More often than not, proper handling of an event depends on
more than just the event type (e.g. also which key or pointer button). CLUE
event specs provide a way to express these more specific conditions. Second,
the possible event types handled by a contact are not fixed at compile-time.
I'm free to have one instance of class C react to pointer input, while all other
C instances do not. And I don't have to define a dummy BUTTON-PRESS method for
C "just in case". Third, event translation (i.e. the binding of an event type
to the function which will process it, for a specific instance) is not
determined at compile-time, but dynamically instead. This allows for event
translations to be read as resources when a contact is initialized, for
individual contacts to add new keystroke bindings, and for event translations to
change to reflect dynamic contact state (a common requirement).
> Why is there :UP, but not :DOWN?
No good reason. :UP is sorta wimpy, since it's only an abbreviation for the
equally-simple :KEY-RELEASE form. It's an example of how to use the general spec
list capability. :DOWN would be equally trivial to implement.
> However even if the CLUE approach to event handling is adopted, I
> don't see the desireability of specifying an association list. Mostly
> this is because of my desire to avoid using lists whenever there's a
> clean efficient alternative.
Fine. The intent was that a non-alist implementation of event-translation should
be possible. The document needs some changes to make this clear.
> I think that what this chapter points out the need for the Common Lisp
> standard to specify a bit more about what streams are and how one goes
> about creating new kinds of streams. Having this all be
> implementation dependant is a real pain (especially when using
> implementations like Lucid which insist on hiding as much of their
> internals as possible!)
Agreed. Mike McMahon <MMcM@scrc-stony-brook.arpa> and others have begun some
work in this area.
∂26-Jan-88 0048 CL-Windows-mailer Comments on CLUE
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 00:48:33 PST
Date: 26 Jan 1988 03:12-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Comments on CLUE
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <570183177/rfb@SPICE.CS.CMU.EDU>
Date: Mon, 25 Jan 88 14:29:38 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
. . .
> In general, I would have guessed that having specializable generic
> functions with names like BUTTON-PRESS, etc. and which accepted
> keyword arguments like those passed to the CLX event handling function
> would have been a better approach than the mechanism proposed in CLUE.
> To specialize event handling, one might define a sub-class of WINDOW
> named BUTTON which specialized ENTER-WINDOW, BUTTON-PRESS, etc. to
> invoke other g.f.'s with names like ACTIVATE-BUTTON, SELECT-BUTTON,
> FIRE-BUTTON, etc.
There are three advantages to the CLUE approach. First, better consolidation of
event dispatching. More often than not, proper handling of an event depends on
more than just the event type (e.g. also which key or pointer button). CLUE
event specs provide a way to express these more specific conditions. Second,
the possible event types handled by a contact are not fixed at compile-time.
I'm free to have one instance of class C react to pointer input, while all other
C instances do not. And I don't have to define a dummy BUTTON-PRESS method for
C "just in case". Third, event translation (i.e. the binding of an event type
to the function which will process it, for a specific instance) is not
determined at compile-time, but dynamically instead. This allows for event
translations to be read as resources when a contact is initialized, for
individual contacts to add new keystroke bindings, and for event translations to
change to reflect dynamic contact state (a common requirement).
I think that there are many classes which one might want to define in a
toolkit which don't require this degree of flexibility. For cases
where the flexibility is desired, the added functionality (and
performance cost) as needed. For example, an EDITOR-WINDOW might
define a KEY-PRESS which made use of its KEYMAP. In my toolkit, an
ACTION-BUTTON is a BUTTON whose FIRE-BUTTON method FUNCALLs its ACTION
slot, but most BUTTONs will be expected to cause the same action
throughout their existance so that action is defined using DEFMETHOD
and is fixed at compile time.
The ability to have one C instance which acts just slightly differently
can be had at the cost of specializing C for that instance. I think
that this class specialization more accurately reflects the semantics
of the situation since the ``special instance'' has slightly different
properties than the other instances, unless pointer-sensistivity is
considered to be a boolean property of C instances in which case there
really needs to be the equivalent of a BUTTON-PRESS method defined for
C.
Rick Busdiecker
Expert Technologies Incorporated
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂27-Jan-88 0921 CL-Windows-mailer CLX and Kyoto Common Lisp
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 09:20:55 PST
Date: Wed 27 Jan 88 11:22:17-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
Subject: CLX and Kyoto Common Lisp
To: cl-windows@SAIL.STANFORD.EDU
cc: lrc.bennett@R20.UTEXAS.EDU
Message-ID: <12369978670.26.LRC.OPPENHEIM@R20.UTEXAS.EDU>
We want to write applications using CLX which will be ported to a
UNIX-based PC. We want to compile the applications using Kyoto CL.
I'd appreciate getting in touch with people who have done something
similar to find out if it's feasible and what the difficulties are.
Thanks.
Jennifer Oppenheim
Linguistics Research Center
University of Texas, Austin
-------
∂27-Jan-88 1708 CL-Windows-mailer Re: Comments on CLUE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 27 Jan 88 17:08:34 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae07294; 27 Jan 88 19:37 EST
Received: from csc.ti.com by RELAY.CS.NET id ad23228; 27 Jan 88 19:26 EST
Received: from dsg by tilde id AA17601; Wed, 27 Jan 88 16:24:03 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Wed, 27 Jan 88 16:22:34 CST
Message-Id: <2779306185-9017282@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Wed, 27 Jan 88 15:29:45 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Rick.Busdiecker@CS.CMU.EDU
Cc: cl-windows@SAIL.STANFORD.EDU, Rick.Busdiecker@SPICE.CS.CMU.EDU
Subject: Re: Comments on CLUE
In-Reply-To: Msg of 4 Jan 1988 14:44-EST from Rick.Busdiecker@spice.cs.cmu.edu
> I also got the impression that a lot of the the (generic) functions
> proposed in CLUE are just arbitrary name changes which don't use
> ``conc-names'' so that they will have a high probability of causing
> all sorts of package conflicts which shouldn't be necessary. PRESENT
> vs. MAP-WINDOW is one example of what I'm talking about.
No, there's no intention to dictate arbitrary name changes. In particular, while
PRESENT and MAP-WINDOW are strongly related, they are distinct operations.
PRESENT, the "higher level" construct, does a bunch of CLUE-specific stuff in
addition to calling MAP-WINDOW.
Re ``conc-names'': here's an issue that has not been adequately addressed. I'd
like to hear everyone's opinion, because I believe it revolves around a question
of proper CLOS style/usage.
First of all, CLOS has changed a bit here: the :accessor-prefix and
:reader-prefix options of defclass are no longer defined. Instead, the
progammer must explicitly define a prefix as part of the :accessor/:reader slot
options for each slot.
It has been suggested that using prefixes in :accessor/:reader names is good
CLOS style.
Note also that a generic function, since it enforces an arglist convention for
all its methods, is not *absolutely* generic; there really is a bit of implicit
semantics there. Therefore, it's appropriate to use a prefix (which denotes the
"implicit semantics") for all generic function names.
So what should we do?
a. Use "<class-name>-" as the prefix for all slot :accessor/:reader
options.
b. Use "<class-name>-" as the prefix for all slot :initarg options.
c. Use "<class-name>-" as the prefix for all CLUE generic functions
(i.e. methods).
∂27-Jan-88 1832 CL-Windows-mailer Re: Comments on CLUE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 18:32:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 330109; Wed 27-Jan-88 21:32:18 EST
Date: Wed, 27 Jan 88 21:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Comments on CLUE
To: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
cc: Rick.Busdiecker@CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <2779306185-9017282@Sierra>
Message-ID: <19880128023218.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 27 Jan 88 15:29:45 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
Re ``conc-names'': here's an issue that has not been adequately addressed. I'd
like to hear everyone's opinion, because I believe it revolves around a question
of proper CLOS style/usage.
First of all, CLOS has changed a bit here: the :accessor-prefix and
:reader-prefix options of defclass are no longer defined. Instead, the
progammer must explicitly define a prefix as part of the :accessor/:reader slot
options for each slot.
That's correct. CLOS endeavours not to promote any particular naming
convention, but to allow each programmer to choose his own. Of course it
would be a disaster if a bunch of programmers working on a single system,
such as the constellation of X-Windows tools, didn't come to an agreement
on a common naming convention. That's common sense. But CLOS didn't want
to force all the programmers in the universe to agree on a common naming
convention.
It has been suggested that using prefixes in :accessor/:reader names is good
CLOS style.
Particularly because it matches the style used by most Common Lisp built-in
functions.
Note also that a generic function, since it enforces an arglist convention for
all its methods, is not *absolutely* generic; there really is a bit of implicit
semantics there. Therefore, it's appropriate to use a prefix (which denotes the
"implicit semantics") for all generic function names.
So what should we do?
a. Use "<class-name>-" as the prefix for all slot :accessor/:reader
options.
b. Use "<class-name>-" as the prefix for all slot :initarg options.
c. Use "<class-name>-" as the prefix for all CLUE generic functions
(i.e. methods).
Note that the proper prefix is usually not the name of the particular class
you are defining, and often not the name of a class at all. The best
prefix is a name describing the whole family of classes that share the
"implicit semantics." Sometimes this is a name of a class that is a common
superclass of all the others, sometimes it is not. Usually it's a very
general word, like "window."
You should certainly use the same convention for a and c, because no one
should have to know whether a generic function they are calling has its
methods defined by defmethod or by :accessor/:reader/:writer slot-option.
I believe that the prefix-dash convention is the right one for a and c.
b is less clear, as is the related issue of whether initialization arguments
are best named with keyword symbols or regular symbols. This depends
primarily on whether you plan to have classes composed as mixtures of
superclasses contributed by very independent modules, or whether all the
classes mixed together will be closely coordinated and therefore can share
a single space of names. Prefixes on initialization arguments can get
awkward, so it's nice to avoid them if you can, but it isn't always
possible. I don't have much wisdom to offer here.
∂27-Jan-88 2103 CL-Windows-mailer mailing address
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:03:46 PST
Date: 28 Jan 1988 00:00-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: CL-Windows@Sail.Stanford.Edu
Cc: Gripe@cs.cmu.edu
Subject: mailing address
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <570344424/rfb@SPICE.CS.CMU.EDU>
Could someone give me the email address for either Lamott Oren or Kerry
Kimbrough. The addresses that I have:
LaMott Oren <Oren@home.csc.ti.com>
Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
bounce from CMU.
Rick
∂27-Jan-88 2129 CL-Windows-mailer Re: mailing address
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:29:16 PST
Received: from SPICE.CS.CMU.EDU by SPICE.CS.CMU.EDU; 28 Jan 88 00:29:05 EST
To: Rick.Busdiecker@cs.cmu.edu
cc: CL-Windows@Sail.Stanford.Edu , Gripe@cs.cmu.edu
Subject: Re: mailing address
In-reply-to: Your message of 28 Jan 88 00:00:00 -0500.
<570344424/rfb@SPICE.CS.CMU.EDU>
Date: Thu, 28 Jan 88 00:28:53 EST
Message-ID: <1867.570346133@SPICE.CS.CMU.EDU>
From: Christopher.Hoover@SPICE.CS.CMU.EDU
Rick,
In Lisp Pointers, I have Kerry Kimbrough's address listed as:
kibmbrough%dsg%ti-csl.csnet@csnet-relay
but I think that would bounce due to lack of a domain name. I would try:
kibmbrough%dsg%ti-csl.csnet@realy.cs.net
LaMott Oren's should follow the same transformation of course.
-- Chris.
∂27-Jan-88 2141 CL-Windows-mailer Re: Comments on CLUE
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 21:41:20 PST
Date: 28 Jan 1988 00:29-EST
From: Rick.Busdiecker@SPICE.CS.CMU.EDU
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>,
CL-Windows@Sail.Stanford.Edu
Subject: Re: Comments on CLUE
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <570346167/rfb@SPICE.CS.CMU.EDU>
Date: Wed, 27 Jan 88 21:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
b is less clear, as is the related issue of whether initialization arguments
are best named with keyword symbols or regular symbols. This depends
primarily on whether you plan to have classes composed as mixtures of
superclasses contributed by very independent modules, or whether all the
classes mixed together will be closely coordinated and therefore can share
a single space of names. Prefixes on initialization arguments can get
awkward, so it's nice to avoid them if you can, but it isn't always
possible. I don't have much wisdom to offer here.
I've been implementing a tool-kit using almost one package per class
and haven't had problems with slot names since I consider them to be
part of the package interface, i.e. exported symbols. A problem with
this is that I'm exporting symbols with names like X and Y which is
begging for conflicts. My solution has been to define a package which
represents the tool-kit as a whole which only the exports non-slot-name
symbols of the various packages which it uses. My idea is that an
application that is simply using the tools/classes, without defining or
specializing any of its own can just USE-PACKAGE this toolkit package.
An application which defines or specializes specific classes which are
part of the toolkit should define a new class in a new package which
only USE-PACKAGEs the packages which it actually uses in the class
definition.
Rick
∂27-Jan-88 2224 CL-Windows-mailer Re: mailing address
Received: from tut.cis.ohio-state.edu (ohio-state.arpa) by SAIL.Stanford.EDU with TCP; 27 Jan 88 22:21:48 PST
Received: by tut.cis.ohio-state.edu (5.54/0.2)
id AA08460; Thu, 28 Jan 88 01:20:28 EST
Message-Id: <8801280620.AA08460@tut.cis.ohio-state.edu>
Date: Thu 28 Jan 88 01:20:18-EST
From: Arun <Welch%osu-20@ohio-state.arpa>
Subject: Re: mailing address
To: Christopher.Hoover@SPICE.CS.CMU.EDU
Cc: Rick.Busdiecker@cs.cmu.edu, CL-Windows@Sail.Stanford.Edu, Gripe@cs.cmu.edu
In-Reply-To: Message from "Christopher.Hoover@SPICE.CS.CMU.EDU" of Thu 28 Jan 88 01:07:28-EST
I've had
Kimbrough%dsg%ti-csl@relay.cs.net
work fine for me. We sit behind csnet-relay, but I don't think that will make
a difference.
What is Lisp Pointers?
...arun
-------
∂27-Jan-88 2258 CL-Windows-mailer Re: mailing address
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Jan 88 22:58:29 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA03741; Wed, 27 Jan 88 22:58:48 PST
Received: By SPAR.SLB.COM (from hobbes.SPAR.SLB.COM)
id AA19626; Wed, 27 Jan 88 22:57:15 PST
Received: By hobbes.SPAR.SLB.COM (from localhost)
id AA00373; Wed, 27 Jan 88 22:57:11 PST
Message-Id: <8801280657.AA00373@hobbes.SPAR.SLB.COM>
To: CL-Windows@Sail.Stanford.Edu
Subject: Re: mailing address
In-Reply-To: Your message of Thu, 28 Jan 88 00:28:53 -0500.
<1867.570346133@SPICE.CS.CMU.EDU>
Date: Wed, 27 Jan 88 22:57:09 -0800
From: malcolm@SPAR.SLB.COM
Sorry to bother the whole net about this......but can somebody send me
a copy of the CLX Hello World example? I thought I had put aside a copy
when it first came over the net but now I can't find it.....argh.
Mucho thanks.
Malcolm Slaney
Schlumberger Palo Alto Research
malcolm@spar.slb.com
∂28-Jan-88 1240 CL-Windows-mailer Question about CLX and Kyoto Common Lisp
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 12:40:31 PST
Date: Thu 28 Jan 88 14:41:44-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
Subject: Question about CLX and Kyoto Common Lisp
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12370277122.8.LRC.OPPENHEIM@R20.UTEXAS.EDU>
We are interested in using X windows in order to port applications
written in CLX to UNIX-based workstations. We want to use a
Kyoto Common Lisp compiler on the workstation. Have you, or do you
know of anyone, who has done something similar? I'd like to know
what kind of problems are involved in compiling CLX applications using
Kyoto CL.
Please respond directly to me, since I'm not yet on the mailing list.
Thanks very much.
Jennifer Oppenheim
lrc.oppenheim@r20.utexas.edu
Linguistics Research Center
University of Texas, Austin
-------
∂28-Jan-88 1956 CL-Windows-mailer Lisp Pointers
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 19:56:08 PST
Received: from SPICE.CS.CMU.EDU by SPICE.CS.CMU.EDU; 28 Jan 88 22:56:52 EST
To: Arun <Welch%osu-20@ohio-state.arpa>
Cc: cl-windows@sail.stanford.edu
Subject: Lisp Pointers
In-reply-to: Your message of Thu, 28 Jan 88 01:20:18 -0500.
<8801280620.AA08460@tut.cis.ohio-state.edu>
Date: Thu, 28 Jan 88 22:56:45 EST
Message-ID: <9749.570427005@SPICE.CS.CMU.EDU>
From: Christopher.Hoover@SPICE.CS.CMU.EDU
``Lisp Pointers'' is a free newsletter which contains technical
articles and various columns on topics such as lisp implementations,
Scheme, and the XJ313 standardization.
To get on the mailing list, send physical mail to:
Lisp Pointers
Mary S. VanDeusen, editor
IBM Watson Research Center
P. O. Box 704
Yorktown Heights, NY 10598
Send her your physical address and state whether or not you object to
getting on various manufacturers' lispy mailing lists.
Volume 1, Number 4 contained an article by Kerry Kimbrough called
``Windows to the Future.'' The article is a quick introduction to
CLX and contains example code.
-- Christopher Hoover
(Christopher.Hoover@CS.CMU.EDU)
∂29-Jan-88 0914 CL-Windows-mailer Question about CLX and Kyoto Common Lisp
Received: from MEAD.SCRC.Symbolics.COM ([128.81.41.234]) by SAIL.Stanford.EDU with TCP; 29 Jan 88 09:14:18 PST
Received: from HAN.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131343; Fri 29-Jan-88 11:44:26 EST
Date: Fri, 29 Jan 88 11:45 EST
From: David Schatsky <schatsky@MEAD.SCRC.Symbolics.COM>
Subject: Question about CLX and Kyoto Common Lisp
To: LRC.OPPENHEIM@R20.UTEXAS.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12370277122.8.LRC.OPPENHEIM@R20.UTEXAS.EDU>
Message-ID: <19880129164549.4.SCHATSKY@HAN.SCRC.Symbolics.COM>
Date: Thu 28 Jan 88 14:41:44-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
We are interested in using X windows in order to port applications
written in CLX to UNIX-based workstations. We want to use a
Kyoto Common Lisp compiler on the workstation. Have you, or do you
know of anyone, who has done something similar? I'd like to know
what kind of problems are involved in compiling CLX applications using
Kyoto CL.
Please respond directly to me, since I'm not yet on the mailing list.
Thanks very much.
Jennifer Oppenheim
lrc.oppenheim@r20.utexas.edu
Linguistics Research Center
University of Texas, Austin
-------
Would people include me in their responses? Thanks.
David Schatsky
Symbolics International Sales
∂29-Jan-88 1332 CL-Windows-mailer CLX resource extensions
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Jan 88 13:32:02 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa08908; 29 Jan 88 14:45 EST
Received: from csc.ti.com by RELAY.CS.NET id aj06767; 29 Jan 88 14:30 EST
Received: from SI by tilde id AA03110; Fri, 29 Jan 88 12:39:28 CST
Message-Id: <2779468677-11407459@SI>
Sender: OREN@si.csc.ti.com
Date: Fri, 29 Jan 88 12:37:57 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX resource extensions
The C language resource functions operate on name and class lists that
go from least-specfic to most-specific. For example:
(application frame menu item1)
In the lisp world, its more convenient and space efficient to go the
other way:
(item1 menu frame application)
When done this way, all items in menu share the same sub-list.
For example, with the C ordering, you've got to do:
(setq item-name-list (append parents-item-name-list (list item-name)))
But with a reversed ordering, its simply:
(setq item-name-list (cons item-name parents-item-name-list))
It bothers me that every item needs to copy its parent's list,
instead of using a single cons. Should CLX resources have a reverse
ordering relative to the C world? Am I still living in the dark ages of
expensive memory? More to the point, are the savings inherent in
reversing the ordering worth the possible confusion?
Please Comment
LaMott
∂01-Feb-88 1425 CL-Windows-mailer Please add me on the Distribution List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Feb 88 14:25:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 01 FEB 88 13:49:54 PST
Date: 1 Feb 88 13:48 PST
From: Tateno.pa@Xerox.COM
Subject: Please add me on the Distribution List
To: cl-windows@sail.stanford.edu
cc: Tateno.pa@Xerox.COM
Message-ID: <880201-134954-2288@Xerox>
I'm an engineer & Resident at Xerox Artificial Intelligence Systems from Fuji
Xerox in Japan. Would you please add me on the Distribution List?
and One Question...
Is it possible for me to get CLX?
//Masa
∂08-Feb-88 1715 CL-Windows-mailer CLX support for NOOP request?
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Feb 88 17:15:41 PST
Received: from suntoo.sun.com (suntoo-bb.sun.com) by Sun.COM (4.0/SMI-3.2)
id AA11660; Mon, 8 Feb 88 17:16:12 PST
Received: by suntoo.sun.com (3.2/SMI-3.2)
id AA07172; Mon, 8 Feb 88 17:18:51 PST
Received: by sunpitt.uucp (3.2/SMI-2.0)
id AA05012; Mon, 8 Feb 88 20:06:33 EST
Received: from frob.sun.com by eti.com (3.2/SMI-3.2)
id AA09129; Fri, 5 Feb 88 12:54:27 EST
Received: by frob.sun.com (3.2/SMI-3.2)
id AA00303; Fri, 5 Feb 88 12:54:57 EST
Date: Fri, 5 Feb 88 12:54:57 EST
From: sunpitt!eti!frob!rick@Sun.COM (Rick Busdiecker)
Message-Id: <8802051754.AA00303@frob.sun.com>
To: sunpitt!sun!sail.stanford.edu!cl-windows@Sun.COM
Subject: CLX support for NOOP request?
Is there any? Should there be?
Rick Busdiecker
Expert Technologies, Inc.
sunpitt!eti!rick@sun.com
or
rfb@cs.cmu.edu
∂09-Feb-88 0821 CL-Windows-mailer Re: CLX support for NOOP request?
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Feb 88 08:21:15 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab08492; 9 Feb 88 11:21 EST
Received: from csc.ti.com by RELAY.CS.NET id ab29329; 9 Feb 88 11:18 EST
Received: from SI by tilde id AA19764; Tue, 9 Feb 88 09:17:11 CST
Message-Id: <2780406918-3713673@SI>
Sender: OREN@si.csc.ti.com
Date: Tue, 9 Feb 88 09:15:18 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: Rick Busdiecker <sunpitt!eti!frob!rick@SUN.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX support for NOOP request?
In-Reply-To: Msg of Fri, 5 Feb 88 12:54:57 EST from Rick Busdiecker <sunpitt!eti!frob!rick@sun.com>
Date: Fri, 5 Feb 88 12:54:57 EST
From: Rick Busdiecker <sunpitt!eti!frob!rick@sun.com>
Subject: CLX support for NOOP request?
Is there any? Should there be?
The following is at the bottom of the CLX/requests.l file:
#+comment ;; This is a protocol request, but its not very interesting...
(defun no-operation (display)
(declare (type display display))
(with-buffer-request (display *x-nooperation*)))
I thought the purpose of the NOOP request was for padding out requests
to a multiple of 64 bits on machines with 64 bit word sizes (i.e. Cray).
I see no need for a user of CLX to send NOOPs, however an implementation
of CLX on a Cray might send NOOP requests.
I suspect the only reason the C Xlib code includes XNoOp is for server
testing. If you're doing server testing with CLX, perhaps the
no-operation function (above) should be a part of your test code, rather
than in CLX. You will probably want to use the CLX macros anyway, to
test server error checking by generating incorrect requests.
∂12-Feb-88 1338 CL-Windows-mailer Re: CLX event queue
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Feb 88 13:38:35 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj29782; 12 Feb 88 15:42 EST
Received: from csc.ti.com by RELAY.CS.NET id aj06849; 12 Feb 88 15:35 EST
Received: from dsg by tilde id AA12303; Fri, 12 Feb 88 13:56:06 CST
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Fri, 12 Feb 88 13:57:30 CST
Message-Id: <2780682848-3857788@Sierra>
Sender: KK@sierra.csc.ti.com
Date: Fri, 12 Feb 88 13:54:08 CST
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: LaMott Oren <Oren@home.csc.ti.com>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: CLX event queue
In-Reply-To: Msg of Fri, 12 Feb 88 13:06:31 CST from LaMott Oren <Oren@Home.TI>
> 2. When discard-p is true, remove the event from the queue BEFORE
> processing the event. This makes the throw behavior "discard"
> when discard-p else "keep". (I favor this option)
This approach would create a problem in CLUE. Since CLUE:PROCESS-NEXT-
EVENT hard-wires discard-p true, the CLUE programmer is unable to elect
"throw but keep". Perhaps CLUE should change to allow the caller of
CLUE:PROCESS-NEXT-EVENT to define discard-p. But this still doesn't
change the problem: a programmer still needs the ability to keep or
discard when throwing, regardless of the default policy of the
surrounding process-event.
> 1. Provide a discard-current-event function.
I favor this approach. How about "pop-event"?
∂12-Feb-88 1403 CL-Windows-mailer CLX event queue
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 12 Feb 88 14:03:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae29782; 12 Feb 88 15:41 EST
Received: from csc.ti.com by RELAY.CS.NET id ae06849; 12 Feb 88 15:34 EST
Received: from SI by tilde id AA11402; Fri, 12 Feb 88 13:08:02 CST
Message-Id: <2780679991-5111499@SI>
Sender: OREN@si.csc.ti.com
Date: Fri, 12 Feb 88 13:06:31 CST
From: LaMott Oren <Oren@home.csc.ti.com>
To: cl-windows@SAIL.STANFORD.EDU
Subject: CLX event queue
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
∂19-Feb-88 1211 CL-Windows-mailer CLX documentation
Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 88 12:11:14 PST
Date: Fri 19 Feb 88 11:33:10-CST
From: LRC.OPPENHEIM@R20.UTEXAS.EDU
Subject: CLX documentation
To: cl-windows@SAIL.STANFORD.EDU
Message-ID: <12376009962.40.LRC.OPPENHEIM@R20.UTEXAS.EDU>
Can someone tell me where I can get some documentation on CLX? Thanks
very much.
Jennifer Oppenheim
lrc.oppenheim@r20.utexas.edu
-------
∂24-Feb-88 1651 CL-Windows-mailer How to handle timeout of 0 in Lucid's Lisp
Received: from csv.rpi.edu (cs.rpi.edu) by SAIL.Stanford.EDU with TCP; 24 Feb 88 16:50:36 PST
Received: by csv.rpi.edu (5.54/1.14)
id AA15909; Wed, 24 Feb 88 19:54:36 EST
Date: Wed, 24 Feb 88 19:54:36 EST
From: harrisr@csv.rpi.edu (Richard Harris)
Message-Id: <8802250054.AA15909@csv.rpi.edu>
To: cl-windows@sail.stanford.edu
Subject: How to handle timeout of 0 in Lucid's Lisp
Rick Busdiecker asks:
>Why doesn't the timeout argument to PROCESS-EVENT and EVENT-LISTEN
>work, i.e. I specify 0 and it hangs (at least in Sun/Lucid)?
It is easy to handle timeout=0 in Lucid with listen.
I also changed xlib:event-loop, since it handled timeouts of 0
differently than other (non-nil) timeouts. I needed both of these
changes in order to make an event handler loop which runs a function
before every time xlib:event-loop needs to wait.
Rick Harris
;From dependent
#-(or symbolics-3600 explorer)
(defun buffer-read-default (display vector start end timeout)
(declare (type display display)
(type buffer-bytes vector)
(type array-index start end)
(type (or null number) timeout))
(declare-buffun)
(let ((stream (display-input-stream display)))
(declare (type stream stream))
(if (and (eql timeout 0) (null (listen stream)))
:timeout
(do* ((i start (index+ i 1))
(c nil))
((index>= i end) nil)
(declare (type array-index i)
(type (or null card8) c))
(setq c (read-byte stream nil nil))
(if c
(setf (aref vector i) c)
(return t))))))
;From input
;The only change here is that what used to be:
; ((or ,result
; (and (endp ,events) ,timeout (zerop ,timeout)))
;is now:
; (,result
(defmacro event-loop ((display event timeout peek-p discard-p force-output-p) &body body)
;; Bind EVENT to the events for DISPLAY.
;; This is the "GUTS" of process-event and event-case.
(let ((previous (gensym))
(events (gensym))
(result (gensym))
(new (gensym)))
`(with-event-queue (,display)
(let ((,previous nil)
(,events (display-event-queue ,display)))
(when (boundp '*recursive-event-queue*)
(setq ,previous *recursive-event-queue*
,events (cdr *recursive-event-queue*)))
(do ((,result nil))
(,result
,result)
; Read events when queue empty
(unless ,events
,(when force-output-p
`(when ,force-output-p (display-force-output ,display)))
(when (wait-for-event ,display ,timeout)
(return nil)) ;; return when timeout exceeded
;; Look at the new events just read. The value of Previous is still good.
(setq ,events (display-new-events ,display)))
; Keep the new-event list updated
(with-event-queue-internal (,display)
;; When event is new, Pop the new-event list
(let ((,new (display-new-events ,display)))
(when (eq ,events ,new)
(setf (display-new-events ,display) (cdr ,new)))))
; Execute the body
(let ((,event (car ,events))
(*recursive-event-queue* ,events))
(setq ,result (progn ,@body))
; Delete entry when ,result was NIL
(if (if ,result
(not ,peek-p)
,discard-p)
(progn ;Delete event
(if ,previous ; When Event in middle of queue,
(setf (cdr ,previous) (cdr ,events)) ;; Destructively splice it out.
(pop (display-event-queue ,display)))
(deallocate-event ,event))
(setq ,previous ,events))) ; Don't delete event - update previous
(pop ,events)
)))))
∂16-Mar-88 1206 CL-Windows-mailer Re: CLX event queue
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:00:42 PST
Received: by ti.com id AA09679; Wed, 16 Mar 88 08:59:30 CST
Received: from SI by tilde id AA05886; Wed, 16 Mar 88 08:57:54 CST
Message-Id: <2783516351-5096244@SI>
Sender: OREN@SI.csc.ti.com
Date: Wed, 16 Mar 88 08:59:11 CST
From: LaMott Oren <Oren@Home.csc.ti.com>
To: John Irwin <franz!sparky!jdi@ucbarpa.berkeley.edu>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Msg of Tue, 15 Mar 88 15:19:24 PST from John Irwin <franz!sparky!jdi@ucbarpa.berkeley.edu>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case?
No. All clue has ever needed was option #2. Kerry Kimbrough thought it
was required, but I talked him out of it.
I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
Did you see my posting to bug-clx@zermatt.lcs.mit.edu with the
implementation for option #2? If you have that patch,
discard-current-event should be as simple as:
(defun discard-current-event ()
;; Re-use the storage allocated to the current event
(deallocate-event (cadr *recursive-event-queue*))
;; Splice current event out of the event queue
(setf (cdr *recursive-event-queue*) (cddr *recursive-event-queue*)))
It seems to me that discard-current-event is dangerous because its too
easy to lose events and you can always find a work-around for not having
it. In addition, the if you call discard-current-event then fall
through the normal event deletion code, the event will be deallocated
twice, which will REALLY wreck havoc [perhaps the deallocate-event call
should be removed from discard-current-event?]. The only place I can
think of where discard-current-event would NOT be dangerous is when used
inside event-case (or process-event) with the :peek-p parameter non-nil
and :discard-p nil.
∂16-Mar-88 1222 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂16-Mar-88 1230 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1346 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1349 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂16-Mar-88 1459 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1729 CL-Windows-mailer Please change my mail address
Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:30:23 PST
Received: from kddlab.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA13014; Tue, 15 Mar 88 23:29:51 EST
Received: by kddlab.kddlabs.junet (4.12/6.2Junet)
id AA27409; Wed, 16 Mar 88 08:40:27+0900
Received: from sonygw.sony.junet (sonygw.ARPA) by sonyve.isrc.sony.junet (1.2/6.3Junet-1.0)
id AA01898; Tue, 15 Mar 88 08:32:51+0900
Received: by sonygw.sony.junet (5.51/6.3Junet-1.0)
id AA00946; Tue, 15 Mar 88 08:32:46+0900
Received: from wsgw.ws.sony.junet (tko2.ARPA) by sonyvd.drc.sony.junet (4.12/6.3Junet-1.0)
id AA22611; Tue, 15 Mar 88 08:26:07+0900
Received: from doi2.ws.sony.junet (doi2.ARPA) by wsgw.ws.sony.junet (4.12/6.3Junet-1.0)
id AA03917; Tue, 15 Mar 88 08:28:18 jst
Received: by doi2.ws.sony.junet (4.12/6.3Junet-1.0)
id AA01199; Mon, 14 Mar 88 08:30:16 jst
Return-Path: <doi@doi2.ws.sony.junet>
Message-Id: <8803132330.AA01199@doi2.ws.sony.junet>
Date: 14 Mar 1988 0830-JST (Monday)
To: cl-windows@sail.stanford.edu
From: kddlab!seismo.css.gov!sonyvd.sony.junet!doi@uunet.UU.NET
Subject: Please change my mail address
Please change my mail address as next.
old address: kddlab!doi%sonyvd.sony.junet@seismo.css.gov
or doi%sonyvd.sony.junet@seismo.css.gov
new address: takegi%ws.sony.junet@uunet.uu.net
Besst Regards. Katsutoshi Doi
∂16-Mar-88 1459 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂16-Mar-88 1729 CL-Windows-mailer Re: CLX event queue
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 88 12:14:43 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
id AA28932; Tue, 15 Mar 88 16:21:24 PST
Received: from sparky by franz (5.5/3.14)
id AA13851; Tue, 15 Mar 88 15:20:08 PST
Received: by sparky (3.2/3.14)
id AA10927; Tue, 15 Mar 88 15:19:25 PST
Return-Path: <sparky!jdi>
Message-Id: <8803152319.AA10927@sparky>
To: LaMott Oren <home.csc.ti.com!Oren@ucbarpa.Berkeley.EDU>
Cc: cl-windows@sail.stanford.edu
Subject: Re: CLX event queue
In-Reply-To: Your message of Fri, 12 Feb 88 13:06:31 CST.
<2780679991-5111499@SI>
Date: Tue, 15 Mar 88 15:19:24 PST
From: John Irwin <franz!sparky!jdi@ucbarpa.Berkeley.EDU>
Well I've just run up against this problem.
There was some mail stating that #2 is not workable with CLUE. Is this still
the case? I think #1 should be provided in any case.
Does #1 exist? If you haven't hacked one up I'll give it a go.
-- John
--------
Your message:
In CLX event-case and process-event, events aren't removed from the
event queue until AFTER the event has been processed. Its done that way
because removing the event is optional, depending on the value returned
by event processing and the discard-p and peek-p parameters.
If the event-processing code wants to THROW out (from error recovery or
whatever) the event is ALWAYS left on the queue. There are several ways
to fix this:
1. Provide a discard-current-event function.
2. When discard-p is true, remove the event from the queue BEFORE
processing the event. This makes the throw behavior "discard"
when discard-p else "keep". (I favor this option)
3. Unless PEEK-P, always remove the event from the queue before
processing the event, and put it back afterwards when needed.
This changes the throw behavior from "keep" to "discard".
4. Same as 3, but under the control of yet another keyword option
(what would the default be?)
--------
∂06-Apr-88 1627 CL-Windows-mailer CLX
Received: from nrl-aic.arpa by SAIL.Stanford.EDU with TCP; 6 Apr 88 16:27:31 PDT
Return-Path: <schultz@nrl-aic.arpa>
Received: Wed, 6 Apr 88 18:23:38 EST by nrl-aic.arpa id AA10672
Date: Wed, 6 Apr 88 18:23:38 EST
From: Alan Schultz <schultz@nrl-aic.arpa>
Message-Id: <8804062323.AA10672@nrl-aic.arpa>
To: cl-windows@sail.stanford.edu
Subject: CLX
------------------------------------------------------------
PLEASE SEND REPLIES DIRECTLY TO schultz@nrl-aic.arpa !!!!!
------------------------------------------------------------
We have a Sun 3/160C running SunOS 3.4. I have just finished installing
X.V11R2 and everything appears to be working fine.
Our lisp is Sun Common Lisp 2.1.1 (Lucid). The problem is in getting
CLX to work. I did the following:
1) Changed all files ending in .l to .lisp
2) cc -c socket.c ;;; to create socket.c as needed on lucid systems
3) uudecoded ms-patch.uu to create make-sequence-patch.lbin
which is automatically loaded by the "#+lucid" directive.
4) Changed the line in "defsystem.lisp" from
.... '("-lc") ...
to
... '("-lresolv" "-lc") ...
after noting that we do have the resolv library. This also was correct
under V11R1 (CLX worked for us then).
5) Started Lisp (and yes, the X server was already started!)
6) > (load "defsystem")
7) > (compile-clx) ;; this worked fine, no unusual problems
8) > (disksave "clx-lisp") ;; to create an image
9) > (quit) ;; quit lisp
Now, when I type clx-lisp, I get my new lisp image with CLX, but I can't
get open-display to work in any way. I tried the programs in CLX/test,
CLX/debug, and I simply typed at the top level...
(setq display (open-display "aic-sun8")), and in all cases, I got back the
message...
>> Failed to connect to server: aic-sun8 0
OPEN-X-STREAM
Required arg 0 (Host): "aic-sun8"
Required arg 1 (Display): 0
Required arg 2 (Protocol): nil
I tried aic-sun8 (which is what 'hostname' returns on my machine, and
works otherwise in X.V11R2), and I tried unix. Note that CLX only wants
the host and an optional display that defaults to 0 as separate arguments
for open-display. "aic-sun8:0.0" is INcorrect under CLX.
Please help. We have an important project on which I must move quickly that
depends on using CLX. I would like to here from anyone that has CLX
working on a Sun.
Alan C. Schultz
Code 5510
Navy Center for Applied Research in Artificial Intelligence (NCAR A I)
Naval Research Laboratory
Washington, D.C. 20375-5000
ARPA: schultz@nrl-aic.arpa
(202) 767-2877
∂14-Apr-88 1224 CL-Windows-mailer CLX Package Name
Received: from CHILES.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 88 12:23:58 PDT
Received: from CHILES.SLISP.CS.CMU.EDU by CHILES.SLISP.CS.CMU.EDU; 14 Apr 88 15:23:53 EDT
To: cl-windows@sail.stanford.edu
Subject: CLX Package Name
Date: Thu, 14 Apr 88 15:23:32 EDT
From: Bill.Chiles@WB1.CS.CMU.EDU
I'm just starting to play with CLX, and I haven't been closely reading this
mailing list. I hope I won't open a sour subject with my query.
Is there a good reason the CLX package name is "XLIB" instead of "CLX"? Can it
be renamed with "XLIB" as a nickname, or can "CLX" be added as a nickname? If
the authors are opposed to changing the name or adding a nickname, does anyone
see any harm in locally adding "CLX" as a nickname and using it in code?
I don't mean to be petty about names, but if there's no cost, I'd feel better
using "CLX".
Bill
∂14-Apr-88 1529 CL-Windows-mailer CLX Package Name
Received: from EXPO.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 88 15:29:07 PDT
Received: from KILLINGTON.LCS.MIT.EDU by EXPO.LCS.MIT.EDU; Thu, 14 Apr 88 18:29:24 EDT
Date: Thu, 14 Apr 88 18:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX Package Name
To: Bill.Chiles@WB1.CS.CMU.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Apr 88 15:23 EDT from Bill.Chiles@WB1.CS.CMU.EDU
Message-Id: <880414182948.7.RWS@KILLINGTON.LCS.MIT.EDU>
Here's some old mail on the subject. I guess I don't really see the point
in adding CLX as a nickname. (Since the designers named the package XLIB,
why would you feel better using CLX? For the same reason the designers
named it X Window System, but people feel better using X-Windows? :-)
Date: Fri, 1 May 87 10:23 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Date: Thu, 30 Apr 87 19:07 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
8. I suggest using another package name, rather than "XLIB" (how about
"CLX"?). Otherwise, we risk adding unnecessarily to the confusion which
already confounds discussions of the many bits and pieces of X (e.g.
"Are you talking about the Lisp Xlib or the C Xlib?"). As with the
language binding, this is just a matter of finding a name that says what
is it is and doesn't say what it isn't.
I dislike "CLX", given that the "CL" part is both redundant and perhaps wrong (there
isn't that much CL about the interface that it couldn't mostly be used in other
dialects). Just "X" is too short. Any other suggestions? Any other objections
to "XLIB"?
I think "XLIB" is a good choice. It's true that there could be confusion
between the Lisp XLIB and the C XLib. But I think this is outweighed by the
benefits of making it clear that both of these things are instances of the
same level of abstraction and modularity. In other words, there really IS a
Lisp one and a C one, and the naming should reflect that reality in order to
make clear the relationship between the two.